Is there already a LAME switch to force an MP3 stream to be a multiple of -x- bytes? (Or a separate utility to internally pad MP3 files to a multiple of -x- bytes... either method would be acceptable.)
Thank you,
- M.
Full Version: Pad MP3 to a multiple of -x- bytes?
To clarify...
All right folks, the MPEG spec allows for frames to have an extra "padding byte" which increases the size of a frame (when implemented) but does not affect the audio quality. This allows the MPEG stream to be more ISO-compliant. Each frame in such a stream may - or may not, as necessary - have a padding byte.
What I hope to find is a method of forcing the stream to conform not to the ISO specifications, but to a strictly enforced multiple of a certain number of bytes. In comparison, the WAV files you use to burn an audio CD must be a multiple of 2352 bytes, plus the WAV header (an additional 44 bytes, unless the header is non-canonical).
If I want to force an MP3 file to be a multiple of 2048 bytes (I have my reasons...), and NOT simply append silence at the end of the track, is there already a way to cause the addition of a padding byte to be dependent upon this restriction?
At most, this should require the addition/removal of 1024 padding bytes. Does anyone already have a way to do this, or would any knowledgeable programmer be willing to attempt it? For reference I am using Windows (so I would request that the solution be possible in this environment), but a cross-platform solution would be most desirable.
Sincerely,
- M.
All right folks, the MPEG spec allows for frames to have an extra "padding byte" which increases the size of a frame (when implemented) but does not affect the audio quality. This allows the MPEG stream to be more ISO-compliant. Each frame in such a stream may - or may not, as necessary - have a padding byte.
What I hope to find is a method of forcing the stream to conform not to the ISO specifications, but to a strictly enforced multiple of a certain number of bytes. In comparison, the WAV files you use to burn an audio CD must be a multiple of 2352 bytes, plus the WAV header (an additional 44 bytes, unless the header is non-canonical).
If I want to force an MP3 file to be a multiple of 2048 bytes (I have my reasons...), and NOT simply append silence at the end of the track, is there already a way to cause the addition of a padding byte to be dependent upon this restriction?
At most, this should require the addition/removal of 1024 padding bytes. Does anyone already have a way to do this, or would any knowledgeable programmer be willing to attempt it? For reference I am using Windows (so I would request that the solution be possible in this environment), but a cross-platform solution would be most desirable.
Sincerely,
- M.
Still hoping for some help on this one - and hoping that the right person just hasn't read it yet. 
To clarify a little more, there is a GOOD reason I would want to do this: It would (in strong but unproven theory!) facilitate truly gapless playback on CD-based MP3 players. Really.
The reason the MP3 files should wind up a multiple of 2048 bytes is similar to the reason you need WAV files to be a multiple of 2352 bytes. On an audio CD, if the WAV is shorter than that sector size, the remaining space in the sector is filled up with zeroes - which results in silence (or if it's not properly padded with silence, will result in a click/pop). Now, on a data CD, the sector size starts as 2352 bytes as well... but 304 of those bytes are used for error checking, and accurate sector location. That leaves 2048 "user bytes" for storing data. If a file is smaller than 2048 bytes, or if its total size is slightly less than a multiple of 2048 bytes, the file still occupies that sector and nothing else can reside there. The next file on the disc will begin in the next sequential sector, even if it would have fit entirely within the already-partially-filled one. Why? Well, this keeps the Table of contents clean and enables a system to locate data files accurately. Only one file may occupy a physical sector, and that's a hard-and-fast rule.
This presents a slight difficulty for all existing CD-based MP3 players (that I am aware of, at least; I own a RioVolt SP-250 and have verified this on other brands as well). Once the player reaches the end of a compressed audio file, and if the file is shorter than the 2048 bytes of user data within the sector, the read laser must phisically re-locate to the next sector. This results in an audible gap - even between songs that were encoded "gaplessly." And when the songs must flow from one to the next in order to sound right, that's a major distraction. (Think in terms of live recordings, jam sessions, multi-movement orchestral pieces, radio shows...)
By removing any necessity for the laser to stop and locate the next sector (that is, by making sure each sector is completely full and contiguous with its successor), this difficulty should be eliminated.
My earlier assumption that this would involve the addition or removal of a maximum 1024 padding bytes was based on the assumption that the file already contained some padding bytes; I must amend that here. If an audio file was encoded with NO padding, this would result in a maximum addition of 2047 padding bytes (... since the original file would already be either the correct size - requiring no padding - or slightly over). Either way, the only manner I know to currently modify files in such a manner would be to open them in a Hex editor, physically change the necessary number of padding bits (within the frame header) and add the same number of padding bytes to the appropriate frames. That would require a few thousand changes per file, and while I'm patient I'm not necessarily THAT patient. Especially since I have a few thousand hours of live recordings.
Any help would be sincerely appreciated. Please. I can see that this post is being read, so if anyone else would like to see the idea developed please respond so the right person (preferably someone both familiar with the MPEG spec and a skilled programmer) will also recognize the need for such a program.
- M.
To clarify a little more, there is a GOOD reason I would want to do this: It would (in strong but unproven theory!) facilitate truly gapless playback on CD-based MP3 players. Really.
The reason the MP3 files should wind up a multiple of 2048 bytes is similar to the reason you need WAV files to be a multiple of 2352 bytes. On an audio CD, if the WAV is shorter than that sector size, the remaining space in the sector is filled up with zeroes - which results in silence (or if it's not properly padded with silence, will result in a click/pop). Now, on a data CD, the sector size starts as 2352 bytes as well... but 304 of those bytes are used for error checking, and accurate sector location. That leaves 2048 "user bytes" for storing data. If a file is smaller than 2048 bytes, or if its total size is slightly less than a multiple of 2048 bytes, the file still occupies that sector and nothing else can reside there. The next file on the disc will begin in the next sequential sector, even if it would have fit entirely within the already-partially-filled one. Why? Well, this keeps the Table of contents clean and enables a system to locate data files accurately. Only one file may occupy a physical sector, and that's a hard-and-fast rule.
This presents a slight difficulty for all existing CD-based MP3 players (that I am aware of, at least; I own a RioVolt SP-250 and have verified this on other brands as well). Once the player reaches the end of a compressed audio file, and if the file is shorter than the 2048 bytes of user data within the sector, the read laser must phisically re-locate to the next sector. This results in an audible gap - even between songs that were encoded "gaplessly." And when the songs must flow from one to the next in order to sound right, that's a major distraction. (Think in terms of live recordings, jam sessions, multi-movement orchestral pieces, radio shows...)
By removing any necessity for the laser to stop and locate the next sector (that is, by making sure each sector is completely full and contiguous with its successor), this difficulty should be eliminated.
My earlier assumption that this would involve the addition or removal of a maximum 1024 padding bytes was based on the assumption that the file already contained some padding bytes; I must amend that here. If an audio file was encoded with NO padding, this would result in a maximum addition of 2047 padding bytes (... since the original file would already be either the correct size - requiring no padding - or slightly over). Either way, the only manner I know to currently modify files in such a manner would be to open them in a Hex editor, physically change the necessary number of padding bits (within the frame header) and add the same number of padding bytes to the appropriate frames. That would require a few thousand changes per file, and while I'm patient I'm not necessarily THAT patient. Especially since I have a few thousand hours of live recordings.
Any help would be sincerely appreciated. Please. I can see that this post is being read, so if anyone else would like to see the idea developed please respond so the right person (preferably someone both familiar with the MPEG spec and a skilled programmer) will also recognize the need for such a program.
- M.
I'm sorry but padding the files would not enable gapless playback. The gaps are not caused by sector aligning. Players have buffers and they read multiple sectors at once so the beginning of next song should already be in memory. But MP3 format always introduces silence to the file ends making gapless playback impossible without tricks. Only way to make it is to have large enough buffer and ignore silences at the beginning and the end of mp3s. I don't believe portable players allow you to do that.
Hi Case. I realize that in standard encoding - when each MP3 file is encoded separately - there will always be a bit of silence at each end of a file. But that is NOT the sort of encoding I use. LAME has an additional switch called "--nogap" which causes each WAV to be encoded sequentially, without closing the encoder. No silence is introduced, because at the end of each song a tiny bit of the next track is buffered and analyzed so that the MPEG frame may be filled. The next MP3 picks up where the first left off. If you merge such files end-to-end, they should play seamlessly.
I repeat (lest anyone else misunderstand): In the sort of MP3 encoding I described, there is NO additional silence included in the file. If you would like to try "gapless" encoding, Speek's newly updated Wav2Lame 1.5 (a frontend for LAME) now supports this feature. You can download it from Speeks frontend pages: http://home.wanadoo.nl/~w.speek/speek.htm
... or here is a direct link: http://home.wanadoo.nl/~w.speek/download/wav2lame.zip
CD-based MP3 players do indeed have buffers, but locating the sector boundary as I described earlier is a very real cause of delay between songs - especially since most CD-based players will not begin buffering the next track until the first reaches its end. Flash-memory players might function differently; I've never tired one. I do know that the Creative Nomad Jukebox allows for true gapless playback with gaplessly encoded files (yes, I've tested one - the MP3s had NO included silence, so the player didn't have to "ignore" anything).
- M.
I repeat (lest anyone else misunderstand): In the sort of MP3 encoding I described, there is NO additional silence included in the file. If you would like to try "gapless" encoding, Speek's newly updated Wav2Lame 1.5 (a frontend for LAME) now supports this feature. You can download it from Speeks frontend pages: http://home.wanadoo.nl/~w.speek/speek.htm
... or here is a direct link: http://home.wanadoo.nl/~w.speek/download/wav2lame.zip
CD-based MP3 players do indeed have buffers, but locating the sector boundary as I described earlier is a very real cause of delay between songs - especially since most CD-based players will not begin buffering the next track until the first reaches its end. Flash-memory players might function differently; I've never tired one. I do know that the Creative Nomad Jukebox allows for true gapless playback with gaplessly encoded files (yes, I've tested one - the MP3s had NO included silence, so the player didn't have to "ignore" anything).
- M.
Ok, --nogap is part of solution, but if the player does not buffer the beginning of next song gapless will never work. The music does not start directly, mp3 has a header that has to be analyzed. Even this would make it impossible to be gapless if the player is not designed for it. But i suggest you to edit manually one file and try it.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.