Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Can gapless playback be restored after iTunSMPB frame is removed? (Read 13482 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Can gapless playback be restored after iTunSMPB frame is removed?

Can gapless playback be restored after iTunSMPB frame is removed?

After cleaning out and repairing some MP3 tags I discovered that some of my files no longer playback gapless. 

MP3/Tag Studio allows for cleaning out extra COM frames but doing so for MP3's ripped by iTunes seems to destroy gapless playback in Foobar 9.5.1 and Winamp 5.53.  From what I have learned by researching these boards, the iTunNORM and iTunSMPB frames are Apple's proposed method for playing gapless albums which differs from the more standard LAME MP3-info method.

Interestingly enough, if I use Foobar2k and click on Utils: Edit MP3 Gapless Playback Information I can set the 'Encoder Delay' to the default 576 for LAME and that seems to be enough to make the MP3's play gapless in Foobar, unfortunately there still is a gap in Winamp.  Since my portable player is not an apple product I am not concerned with trying to rebuild those frames, and in fact prefer the LAME MP3-info method for gapless playback.  After researching and experimenting with Foobar, I figured I would post here to see if I am on the right track or if there is a better method.

Is there a general consensus on which is the preferred method and/or apps for restoring gapless playback for both Foobar and Winamp if I no longer had access to the original CD's?

Thanks in advance,
NeuroB

Can gapless playback be restored after iTunSMPB frame is removed?

Reply #1 –
OK...here is my solution:

(Sorry for replying to myself, but after 3 days no one else offered any advice and hopefully someone else will find this information useful)


Background:

As mentioned above, music ripped through iTunes 7 does not create a XING/INFO header within the first frame of the mp3 and thus there also is no LAME header telling some players how to play gapless.  iTunes stores the info needed for gapless playback inside ID3v2 tags at the top of the file as extra comments inside the ID3v2 tag -- mainly as iTunSMPB and iTunNORM.  There are others like iTunPGAP, but the primary comment that holds the most important hex values is iTunSMPB. The 2nd value is encoder delay (528 for iTunes), the 3rd value is zero-padding, and the 4th hex value is the length in samples of the original track.  Here is a great discussion on this topic: http://www.hydrogenaudio.org/forums/index....8231&st=136

Personally, I don't like a bunch of junk data and frames inside the meta-tags since who knows what else is in there and what its purpose is.  If you are like me and you like your MP3's to be clean and as simple as possible then it would be nice to dump the extra junk data and just have the encoder delay and padding stored inside a LAME header.

Interestingly enough Winamp 5.53 is able to successfully read the iTunes Comments and can play back the album gapless, but Foobar2K 9.5.1 does not recognize these values as legit delay and padding values.


Problem:

So there is no problem if you chose to keep these comments, but if you remove them like I do (so that you have very clean ID3 tags) you will no longer be able to play the songs gapless within Winamp, and as I said before they already do not play gapless in Foobar.


Partial Solution:

In Foobar If you use the 'Utils: Edit MP3 Gapless Playback Information' you can add the encoder delay and sample length back into the file.  You will need to simply convert the hex values to decimal, but that should be enough to tell Foobar how to play the tracks back gapless.  So it would seem that the problem is solved, and it is if you only play the tracks back in Foobar.  But Winamp will not accept these values from Foobar and since the Comment frames are gone also, you will not be able to play gapless in Winamp.

This seems strange to me that Foobar's method for adding a XING/INFO header is not robust enough for Winamp to read the encoder delay and padding values inside the LAME header.  From what I can tell this is not the case if the file already has a XING (VBR, ABR) or INFO (CBR) header, say if your files were ripped with EAC + LAME.  If the files already have a correctly formed header, then Foobar is able to change the enc_delay and padding values and Winamp can also see these values and neither one has any problems playing gapless.

But for some reason, when there is no header there to begin with, Foobar does not create the header in a way that Winamp can see it or read the correct values therein.  I am not sure who is right or wrong in this, Foobar or Winamp, or neither if the LAME header Spec is too non-specific and/or not fully supported.


Full Solution:

After having researched the LAME tag from: http://gabriel.mp3-tech.org/mp3infotag.html I soon discovered why Foobar is making a LAME header that Winamp cannot read.  It is because using the 'Utils: Edit MP3 Gapless Playback Information' on files with no original XING/INFO header, Foobar does not insert the 9-byte Encoder Short Version String into the header (either by mistake or by design).  It instead inserts 9 bytes of 0x20 which is ASCII char 32, or simply 'blank spaces' In both VBR and CBR.  The delay and padding values start 13 bytes away from the end of this string and that is the correct place for them to be.  So it seems that without the Encoder Version String Winamp passes right over the values and ignores them.  I simply used my hex editor to overwrite the first 8 bytes of blank spaces with 'LAME3.97' and suddenly Winamp is able to see the corrected delay and padding values and also play the iTunes encoded songs gaplessly just as Foobar does.  This works for both VBR and CBR iTunes 7 ripped songs and is one method of getting rid of the iTunes method for gapless playback while still preserving gapless playback.

It would be great if in future Foobar releases that you had the option of adding the LAME Encoder Short Version String when you edit the gapless information.


~NeuroB

Can gapless playback be restored after iTunSMPB frame is removed?

Reply #2 –
Give mp3packer a go and see if that solves the issue for you?

Can gapless playback be restored after iTunSMPB frame is removed?

Reply #3 –
Sorry to sound rude, but can I ask what the point of micro-managing your tags to such a degree is, especially if it seems to be just causing you more work anyway? Do some players have a problem with the tags iTunes adds or is there some incompatibility somewhere? 

Can gapless playback be restored after iTunSMPB frame is removed?

Reply #4 –
Quote
Sorry to sound rude, but can I ask what the point of micro-managing your tags to such a degree is, especially if it seems to be just causing you more work anyway? Do some players have a problem with the tags iTunes adds or is there some incompatibility somewhere?

Well yes, Foobar does not play iTunes ripped songs gaplessly unless you add the encoder delay and padding manually.

But as far as micromanaging tags, I really just do not like extra data inside my MP3's.  Call me a bit paranoid, but the fact that Apple puts all those codes in there and the fact that WMP adds data into your tags every single time you play a song, makes me wonder if there is not some tracking of what music you may have, or you may not have, legitimately purchased.

Quote
Give mp3packer a go and see if that solves the issue for you?

I def check it out...thanks

~NeuroB

Can gapless playback be restored after iTunSMPB frame is removed?

Reply #5 –
Quote from: NeuroB on
Quote
Give mp3packer a go and see if that solves the issue for you?

I def check it out...thanks

~NeuroB


Neuro -- did you try mp3packer in conjunction with your earlier formula?  Your original follow-up was useful and interesting to me.  I'm curious to know about the efficacy or lack thereof of mp3packer to solve your blank-space issue.

Thanks!