gap detect

[dryrock]

In the FAQ, in the section on gapless playback, is this:

Other players cut off any zero data (or near zero data) in the final frame of an MP3. This method, which is sometimes referred to as "gap detect" or "gap delete," is not truly gapless, because (1) is it not accurate, and (2) it will cut off silence that is supposed to be at the end of a track. "Gapless" will play back MP3s of a CD the way the mastering engineer intended it to be; "gap detect" or "gap delete" will not. For example, if the mastering engineer decided to put a 2-second gap between one song and another on a CD, true gapless playback will retain that 2-second gap, whereas gap detect or gap delete will not. Rockbox uses gapless playback, not gap detect or gap delete.

I am trying to understand exactly what is wrong with doing this other than the fact that rockbox can't know for sure whether it's the right thing to do.

My feeling is that if you are cutting off zero data in the final frame only, the risk of error is infinitesimally small. Obviously you would only do this if the frame is not ALL zeroes. You're talking about removing a maximum of what, 1/13 second of silence (576 samples at 8khz)? Removal of an extra tiny bit of silence is going to be MUCH less audible in many cases than insertion of that same amount of extra silence.

The part about the 2-second gap is also a bit misleading - again we are talking about not removing ALL trailing silence, just in the last frame. In the absence of knowing what the mastering engineer wanted, I think it is more correct to omit that silence than include it.

The advantage of doing this is that we don't need to worry about how our mp3's were encoded. If the proper LAME information is there, use it, and don't do any trimming. But if it's not, I personally am willing to give up 1/13 second of intentional silence to avoid hearing 1/13 second of unintentional silence. And making it an option gives the user control.

[Llorean]

Or just encode your files properly, and it's not a problem.

[dryrock]

I think that software should make life easier on the user, not harder. To the extent practical, it should make the best of sub-optimal input, not make the user optimize the input for its needs. 

If I can spend a couple hours patching rockbox to improve my experience, that's a big gain over re-encoding a bunch of my old mp3's (granted, by coincidence, I used lame to encode most of the ones that need gapless).

[saratoga]

I think that software should make life easier on the user, not harder. To the extent practical, it should make the best of sub-optimal input, not make the user optimize the input for its needs. 

MP3 encoders have been gapless for a decade now.  You're welcome to add support for this, but its a lot of work for something thats really not that useful to most people.

[bluebrother]

I think that software should make life easier on the user, not harder. To the extent practical, it should make the best of sub-optimal input, not make the user optimize the input for its needs. 

This leaves one question open: which software in the process encoding - decoding should make life easier? The encoding software or the decoding one? Since you usually encode less often than you decode I'd vote for the encoder.

[dryrock]

Think of it in terms of old-fashioned analog recording. Obviously when you make a recording you want to do the best job you can, to make it easy to make playback sound the best. Down the road a stretch, for playback, you want equipment that you can adjust to make the most of the recordings you have, rather than telling you you were a dolt for not doing something different when you recorded it and that the only way to make it sound better is to re-record it.

Let's say you had a tape deck that did not have Dolby noise reduction and you recorded a bunch of albums on it. Then you get a tape deck with Dolby NR and some other audio improvements. You can re-record all your albums to take advantage of the new tech, but most people won't. They'll count on the other improvements to make the most of their existing recordings.

So I kind of think the opposite of what you said. The process you do more often -- decode -- should be easier (make up for the deficiencies of the process you do less often).

[saratoga]

So I kind of think the opposite of what you said. The process you do more often -- decode -- should be easier (make up for the deficiencies of the process you do less often).

Most people won't agree with your assessment, but if it works for you, thats good enough.  Submit a patch for doing gap detection properly and I'll try and find time to review it.

[dryrock]

I have a little different appreciation for this question now...

Adding in code to chop off zeroes at the end of the last frame was quite simple. But I kept hearing this gap between my test tracks.

In my debugging it became clear that the last frame had no trailing zeroes (or close to zeroes).  So why am I still hearing this gap?

Other tracks encoded with lame, or ogg tracks, were playing perfectly gaplessly. 

So I opened up the test tracks with Audacity and what do I see?

There is approximately a full frame of silence at the BEGINNING of each of these tracks.  Why the heck would an mp3 encoder do THAT???  (I believe these were ripped directly from cd to mp3 with a recent version of itunes).

So I pulled out some other old tracks. These I knew I had as wavs and had used itunes to convert to mp3 (it was the path of least resistance at the time). They similarly have a gap at the BEGINNING (and it appears possibly at the end).

Poking around it seems that iTunes has its own gapless methodology and it is possible to get the beginning and ending padding from the id3 tags. This may be a pain but I am going to have to see if I can make use of that similar to the LAME tags.

[saratoga]

There is approximately a full frame of silence at the BEGINNING of each of these tracks.  Why the heck would an mp3 encoder do THAT???  (I believe these were ripped directly from cd to mp3 with a recent version of itunes).

Because the filterbank used in mp3 has several hundred samples of delay at the beginning:

http://lame.sourceforge.net/tech-FAQ.txt

Poking around it seems that iTunes has its own gapless methodology and it is possible to get the beginning and ending padding from the id3 tags. This may be a pain but I am going to have to see if I can make use of that similar to the LAME tags.

We already do this:

http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22872

[dryrock]

There is approximately a full frame of silence at the BEGINNING of each of these tracks.  Why the heck would an mp3 encoder do THAT???  (I believe these were ripped directly from cd to mp3 with a recent version of itunes).

Because the filterbank used in mp3 has several hundred samples of delay at the beginning:

http://lame.sourceforge.net/tech-FAQ.txt

Ok, so if I understand things correctly, in the absence of a LAME header specifying the exact number of extra samples at the beginning, the decoder just skips a pre-set amount. So what I am hearing in my badly-encoded tracks is the remaining ~540 zero-ish samples.

When I import the mp3 into Audacity, Audacity may not skip any of the beginning samples. It is close to a full frame of zero-ish data at the beginning.

Poking around it seems that iTunes has its own gapless methodology and it is possible to get the beginning and ending padding from the id3 tags. This may be a pain but I am going to have to see if I can make use of that similar to the LAME tags.

We already do this:

http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22872

Cool! It appears that my itunes-encoded test files predate this feature in itunes's encoding.

The end result is that as of now, I have routines to optionally chop off zero-ish data at the beginning of the first, or end of the last, frame. Audibly it has fixed my issue and I get gapless mp3 playback now with my bad mp3's -- and it doesn't appear to screw up lame-encoded ones :-) I need to do some cleanup before I submit any patches.

I do still have some stupid tracks that were converted to WMA automatically by WMP and those are going to get re-ripped to mp3 by modern software. But I don't have to re-rip all the ones I did using iTunes in the old days.

Thank you for your patience as I learned my way around. 

[saratoga]

Ok, so if I understand things correctly, in the absence of a LAME header specifying the exact number of extra samples at the beginning, the decoder just skips a pre-set amount. So what I am hearing in my badly-encoded tracks is the remaining ~540 zero-ish samples.

When I import the mp3 into Audacity, Audacity may not skip any of the beginning samples. It is close to a full frame of zero-ish data at the beginning.

Its up to the decoder.  If theres no lame or itunes tag info, then the mp3 doesn't have a precisely defined length, and the software can do as it pleases.  Often this means different applications will produce different length wav files from the same mp3.

Cool! It appears that my itunes-encoded test files predate this feature in itunes's encoding.

If you update iTunes to a semimodern version, you can have it scan all tracks for missing lame gapless headers, and then try to reconstruct them as best it can (using the method you propose here). 

The end result is that as of now, I have routines to optionally chop off zero-ish data at the beginning of the first, or end of the last, frame. Audibly it has fixed my issue and I get gapless mp3 playback now with my bad mp3's -- and it doesn't appear to screw up lame-encoded ones :-) I need to do some cleanup before I submit any patches.

Hopefully you're doing this somewhere in or near dsp.c right?

[dryrock]

If you update iTunes to a semimodern version, you can have it scan all tracks for missing lame gapless headers, and then try to reconstruct them as best it can (using the method you propose here). 

Hm, I may have to try that. I do not have all my music in iTunes.

Hopefully you're doing this somewhere in or near dsp.c right?

Actually it's in mpa.c. In there I can easily tell what is the first and last frame and I just adjust the parameters to the pcmbuf_insert call. It restricts this to working with mp3 only I know.

[dryrock]

Ok, I submitted a first patch (11891):

http://www.rockbox.org/tracker/task/11891