Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Alex B]

I posted this in the 11.1.174 thread:

When a gapless album (a DJ mix etc), which is in the disc image mp3 & cue format is played MC uses the gapless encoder delay and padding values from the main LAME encoded disc image file. It reads the info and obviously uses the same values for each track. This incorrectly removes some of the audio content and can add audible clicks on the track boundaries.

I tested this by removing the delay and padding information from the the main file. After that the cue tracks inside MC were correctly gapless.

This could be fixed if MC would not use the gapless LAME decoding when a track contains a playback range that does not start or end with 0. When the playback range starts with 0 MC should use only the encoder delay information and when the range ends with 0 it should use the padding information. If the playback range is 0-0 MC should use the both values. (I have a few 0-0 playback ranges because I have made some virtual tracks by using custom cue sheets that point to standard track files.)

11.1.175 has the same problem.

For making testing this easier I combined the same short audio clips that I used for debugging
the new gapless MP3 decoding system into a single audio file and made a cue sheet for it:

CombinedClipsAndCue.zip (845 KB)

It is easy to compare the cue tracks and the source audio file just by listening to them separately.

If the playback range based system is not possible (for now?) the second best option would be to just eliminate the gapless LAME decoding whenever a cue track is played (for example, when the track name contains ".mp3;").

[hit_ny]

Good catch Alex...

..now lets see if it gets fixed

[Alex B]

This seems to be an unexpected side effect of the otherwise excellent gapless LAME playback support. Naturally, the cue playback must be gapless too. It has been working gaplessly since August 2004. Of course, this should be fixed as soon as possible.

Besides the standard CD audio disc images I have used cue sheets a lot for making seek points to other audio files that are not ripped from CDs (like live recordings, recorded radio shows, vinyl recordings from gaplessly mastered LPs and some other audio projects). LAME encoded VBR MP3 has been a natural compression format choice for such a material because it is widely supported and has quite high quality. Some of that material does not exist in any other format. Currently I would make lossless archive files, but a couple of years ago the situation was different.

[Matt]

Should be changed next build.

Thanks Alex.

[hit_ny]

Quote
1. Changed: LAME MP3 tail bytes ignored when playing from CUE files.

If this means the problem with gapless playback of LAME encoded CUE tracks I don't think the fix is working yet. Please, compare the cue tracks and the source MP3 file from my sample package: CombinedClipsAndCue.zip (845 KB)

Also, because this cue file does not contain track names MC displays the names as Track01, Track02, Track03 etc. However, the Name field of the first track stays empty and "Track01" shows up in the Album field.

Does this still apply with 11.1.178 ?

[Alex B]

Does this still apply with 11.1.178 ?

Yes.

[hit_ny]

Dang , let's hope it gets looked at.

[hit_ny]

*BUMP*

...why wait another yr

[Matt]

Next build:
Changed: Gapless handling of LAME MP3 files from CUE files is now perfect like non-CUE playback.

Thanks guys.

[Alex B]

Seems to be working fine now. Thank You!

May I ask how did you fix it? Do you use the playback range info or something else?

[Matt]

Seems to be working fine now. Thank You!

May I ask how did you fix it? Do you use the playback range info or something else?

We added sample-perfect MP3 seeking a while ago.  (which isn't a trivial thing)

With gapless LAME support, we needed to account for the header padding, footer padding, and decoder delay.

Then with CUE support, it's just a matter of making sure the right pieces are accounted for in each case. (i.e. no need to look at header or footer padding for a track in the middle, but decoder delay is still relevant)

Hopefully that answers the question.

[Alex B]

Thanks for the explanation.

If someone wants to know what these paddings and delays mean, these old links may help:
http://lame.sourceforge.net/tech-FAQ.txt
http://mp3decoders.mp3-tech.org/decoders_lame.html

EDIT

This is a nice page too:
http://mp3decoders.mp3-tech.org/decoders_mjb.html   

[hit_ny]

Excellent work 

Thx for the effort.