Really odd possible bug with importing multi-track file

Getting Stuff Done How do I .... ?
#1

Ok, I’m stumped on this one… its consistently wrong. The “sometimes works” was due to working ok with modified stereo tracks.

I’m currently re-formatting some sampled drum files using ffmpeg to make the sound files more appropriate for playing “live” (or at least triggered by midi and/or a midi roll). The idea is to merge the stereo into mono so that I can I can pan it to my hearts content and also so I can pitch shift the toms a bit so I can fake a couple more than there are samples available.

This is done by the following:
Extract all channels into mono files.
Merge stereo pairs into single mono files.
Merge resulting files into single multi-channel file.

As an example this is what happens with the kick drum (7 channels mixed down to 5).
ComplextFile > KickIn KickOut KickBase Overhead-L Overhead-R Room-L Room-R
Overhead-L & Overhead R > Overhead-Mono
Room-L & Room-R > Room-Mono
KickIn KickOut KickBase Overhead-Mono Room-Mono > NewComplexFile

To make sure everything works as expected I then import the 5 mono tracks, and the NewComplexFile twice (once as 1 track per file, and once as 1 track per channel).

Looking at the visual representation of the tracks everything seems good. All the mono track pairs (KickIn KickOut KickBase Overhead-Mono Room-Mono) match up from the initial mono creation and the one track per channel. The tracks in the new multi-track file also match up visually with the mono track (Channel 1 matches KickIn, etc.)

I then disconnect all the track outputs as they go to master (not where I want them) and then route all the mono tracks (all 10) to a bus (headphone) that goes out to the headphones (channel 3&4) of my audio device.

Playing back the mono files and comparing KickIn(original extract and created mono merge tracks) to KickIn(extract from NewComplexfile) they match up correctly. The same holds true of all the other pairs of identical files.

For the NewComplexFile track sometimes a channel will not match its mono track and sometimes a channel will be exactly the same for more than one mono track. All the visual representations of the channels stay consistent with their expected channel.

For this particular instrument the channels are doing the following:
Channel1=Extract2
Channel2=Extract4
Channel3=Extract3
Channel4=Extract5
Channel5=Extract5

The issue seems to be consistent across all processed recordings for that instrument.

Listening to the tracks, there seems to be an audio disparity between what the duplicated (last two channels in the NewComplexFile, but individually selected) channel sounds like and what the extracted track sounds like. It sounds like the NewComplexFile channel 4 or 5 are the same as the Extract5 and Extract1 combined, or it might be Extract4 doubled (my hearing says either of those are so close its difficult to tell but the Extract5 and Extract1 seem to be slightly ahread).

For a 5 channel instrument mixed down to 4
Channel1=Extract2
Channel2=Extract3
Channel3=Extract4
Channel4=Extract4

For a 4 channel (just overheads and room, such as for cymbals) there are no issues with the resulting two channel file.

Things I’ve done to narrow down the issue.
Tested multiple drum instruments.
Rebooted.
Created new session.
Imported just a single instrument, and multiple instruments, and single instrument multiple times.

Tested an original 7 track kick sample which exhibits the same issue.

The original files were not created by myself. The credit goes to a Mr James Peters Original source.

I’ve uploaded a single multi channel recording, the script, the original extracted files, the combined stereo to monos, and the new multi channel file.

Link to 7z of files.

Edited to add: I’m on Debian Forky and Ardour is Ardour9.7.0~ds (built using 9.7.0~ds-1 and GCC version 15.3.0)

1 Like
#2

Turns out not a bug with Ardour but maybe a misunderstanding and a possible bug with ffmpeg.

What I was doing was: importing an X channel drum .wav file as a single track & as 1 track per channel > deselecting all the routing for the multi channel > connecting channel 1 of the multi channel to L+R in master comparing it to the single track version > then deselecting channel 1. Then repeating that for channel 2/3/4 etc.

Issue one, the fancy panning thing (unchanged since import) was causing single channel selections to have sound from other channels bleed into them. So (as an example) trying to listen to channel 1 in L&R would also pull in a channel 2 and maybe channel 3 even though the the routing grid only selected channel 1 to be fed equally into L & R of master. Right clicking on the panning widget and selecting bypass resolved the bleed/merging issue. What really confused me with that is the fact that I could see that visually each channel in the single track matched up to the extracted single channels but the sounds were differing. It didn’t help that for multiple drum kit sounds the close mics, overheads, and rooms all sounded very similar (maybe slight ringing, or volume, or reverb, etc differences) so it was difficult to tell if say the overhead left channel was getting merged into the close mic 1 channel, and so on.

It was only after I’d created a multi channel audio export from Ardour of me speaking the channel names that the Ardour “bleed” issue became apparent (I’d been reading about bypassing stereo panning when exporting “stereo” as multi channel mono’s that I wondered if something similar could be done with the spacial panning widget) that the real channel “mixing” when splitting channels became apparent.

So bug or “it doesn’t work how you think it does; its not the same as normal panning but in more dimensions” that part of the problem is now resolved by using bypass.

Now ffmpeg however… when you pass parameters to -filter_complex channelsplit=channel_layout= then depending on the channel layout sometimes it does what you think it should and other times it does not, even when the number of channels is the same. If, for example, you pass quad[OH-L][OH-R][RM-L][RM-R] then it starts to muddle multiple channels into the individual (4) channel split files. If you pass 4.0[OH-L][OH-R][RM-L][RM-R] then each channel extract contains the correct channel from the multi channel file. The same issue, but only really to one channel extract file, also happens with 5, 6, and 7 channel files (having run multiple tests for multiple layouts, one after the other, its now all a bit of a muddle which ones don’t work - but for the ones that do work as assume I’ve left those options in and alone!). I’ve raised a bug/issue on ffmpeg so I’ll hopefully find out if its a bug or another “it doesn’t work that way” issue.

Now to start setting up correct files to be used by drumgizmo (after checking the splits/mixes/merges all work as intended). Phew… that was a lot of “oh, oh right, that makes sense, wait what!”.

1 Like