b669: Mixdown doesn't seem to read the Cue In Tag...

When I’ve mixed down some shows I noticed I seemed to have some gaps at the end of stuff/beginning of songs, yet when I play the sequence in Auto (or linked) I had no gap.

In investigating, it looks like the mixdown is starting to “mix” the file from the beginning rather than the actual marked CUE IN. Here is an example of the same sequence, one played in AUTO and recorded in real-time, the other is the Mixdown. The song I play at the end has a cue in of 380mS which the gap seems to be about about (after the Fade Out marker on the jingle marker).

Both files are short, just a few seconds.

TEST AUTO MP3
TEST MIXDOWN MP3

There is a difference and clearly visible in an editor waveform.

Version and build number? There was a bug a while back which should have been fixed since a few builds ago.

3.0.12 b669

It seems to be fine with the Fade out etc. I remember the fix, and about 90% start at zero but a lot do have silence or a slow fade in so CUE IN.

I had some time to experiment this morning, took the same file and added silence for a few seconds at the beginning, and I’m afraid it’s inconclusive. BY setting cue points correctly, all behaved (ish). This was with just two files.

Now, I did discover I get differing results by exporting to .WAV (CD Quality, 44.1kHz 16bit etc) than I do to a 320k MP3 file. Same playlist.

I had some odd gaps on a show I did this weekend to .WAV, I would repeat the export having touched nothing and some of the previous loose gaps were now tight and some of the previous correct segues were now looser.

In exporting that show to MP3 (320k), it appears correct and matches the playlist if played in AUTO.

So I think the export to WAV has some little quirks whereas the MP3 (using LAME) seems fine. :slight_smile:

I was exporting as WAV for editing before I exported to MP3.

Hope that helps more, Richard

I have a very vague idea of what’s happening here.

When a file has ended or the Fade Out point is reached, BASS will send a notification to mAirList, which is then passed to the mixdown engine which in turn will start a new file. That notification is passed asynchronously, that is, using the internal messaging system inside mAirList. When the CPU load is rather high (remember that you’re encoding to MP3 at that time), the notification might be delayed a few milliseconds. You won’t really notice that in realtime automated playback (or container playback, which uses the same mechanisms as mixdown does), but during mixdown, which is performed at say 8x speed, the delay increases by factor 8 as well, which might result in the gaps you’re experiencing.

This seems to be a major disadvantage of the current design of the mixdown system. It’s basically a virtual soundcard wired to the encoder, and then a container item is played back into that soundcard - but using the same messaging mechanisms used for realtime playback.

The only solution I could think of is a complete rewrite of the mixdown system. That’s not too difficult, but it will take some time.

[quote=“Torben, post:5, topic:6526”]I have a very vague idea of what’s happening here.

When a file has ended or the Fade Out point is reached, BASS will send a notification to mAirList, which is then passed to the mixdown engine which in turn will start a new file. That notification is passed asynchronously, that is, using the internal messaging system inside mAirList. When the CPU load is rather high (remember that you’re encoding to MP3 at that time), the notification might be delayed a few milliseconds. You won’t really notice that in realtime automated playback (or container playback, which uses the same mechanisms as mixdown does), but during mixdown, which is performed at say 8x speed, the delay increases by factor 8 as well, which might result in the gaps you’re experiencing.

This seems to be a major disadvantage of the current design of the mixdown system. It’s basically a virtual soundcard wired to the encoder, and then a container item is played back into that soundcard - but using the same messaging mechanisms used for realtime playback.

The only solution I could think of is a complete rewrite of the mixdown system. That’s not too difficult, but it will take some time.[/quote]

Thanks. However, it’s the WAV files that seem to experience the issue more, MP3 mixdowns seem to be correlated more to the playout. Let me do a few more shows this way and see what happens before you get bogged down in a mixdown rewrite. It’s possible the WAV export may use more CPU.

Testing, LAME (320k MP3) export,LAME.EXE sits around 50% with mAirlist at 7-10%
WAV export, mAirlist runs around 25-30%.

So LAME does the grunt work I guess on the export, the compression.

This isn’t a showstopper, so I would rather see more work on 3.1 or Voicetracking than fix something that maybe just a few use :slight_smile: (just my humble opinion!)

Much appreciated.

Actually the code required for accurate mixdown is pretty similar to what we need later for voice tracking, so I think it’s worth fixing this.

Hi Torben,

I’m hopefully going to get a bit of time tonight to test mixdowns again, was anything done to the code since we posted this earlier this year?

Any news on true Voicetracking as well? (I was asked by a radio colleague of mine last week).

Thanks and Happy Holidays.

No official news yet. But there will be voice tracking.

By the way, please consider upgrading to v3.1.

[quote=“Torben, post:9, topic:6526”]No official news yet. But there will be voice tracking.

By the way, please consider upgrading to v3.1.[/quote]

Thanks.

Yes, I’m 3.1 but didn’t seen anything in the changelog regarding mixdowns other than cue data etc.

True, but you did say you are on build 669 and the current one is build 854: quite a gap!

I can add to this discussion that when I’ve tried to ‘mixdown’ a playlist which has been processed by my IVP script in the past, things didn’t seem to work properly: tracks weren’t faded down properly, and didn’t start/end appropriately. Though I admit, that was again quite a few builds back, so I need to try it again soon.

I have a (much-needed!) completely free day tomorrow—well, apart from a brief visit to the dentist—so I’ll investigate it again then, and will report back.

BFN
CAD

Mea Culpa, I just revived an old thread. I’ve been on 3.1 for a wee while, just updated to latest so will try a couple of tests. That’s what I found, I would IVP a playlist, and manually playing sounded good, but the results on a mixdown were not consistent.

I’ll put my findings on the 3.1 forum.

Cheers

Don’t worry, Richard: I’m ahead of you here, and have just posted a new topic here:
http://forum.mairlist.com/index.php/topic,4892.0.html

BFN
CAD