Noticed recently that mp3s rendered from montages are being padded, front and back, with unwanted silence. The resulting file can be an extra second longer than intended. So if you have an album with contiguous audio, and you render each CD track as an individual mp3, then the result is interrupted/silent program at track boundaries. Tested with WL 5, 6 & 8; Windows XPpro and 7pro64; and 7 different computers.
Is this a known bug, a limitation of mp3 formatting, or do I have a preference incorrectly set?
MP3s will hardly ever play seamlessly back to back - depending on the player (and its buffer, more importantly). But a whole second sounds very strange, there must be more going on. One thing may be that you render from CD-markers which can be placed not exactly on start and end of audio because of CD frame quantization. Maybe you can test by selecting just clips for rendering.
Just to create a specific example: I imported a 2min file of a 1kHz tone, 16/44. Placed a split marker @ 1min to create a 2track album. Made sure the markers were on CD frame. Then rendered according to markers, by time selection, and by clip selection. In every case each 1min track was rendered as a 1min29ms mp3: 25ms of silence at the head, and 4ms of silence added at the back.
25ms of silence at the head, and 4ms of silence added at the back is typically what I also see when rendering mp3/AAC files.
There has been talk (I think) about PG implementing a way for Wavelab to compensate for this silence but it would probably not be easy or perfect, it seems to be the nature of the mp3 codec for whatever reason.
I was recently mastering a live album and wanted to provide the client with fully tagged AAC files, and I some luck using Sonnox Codec Toolbox to change the rendered files (AAC in my case) to “gapless”. Doing this made for smooth transitions in many players, but not all.
I do wonder if Wavelab has, or could implement a way to tag AAC and mp3 files as gapless or part of a compilation as you can do in other tagging software.
Players sometimes compensate, sometimes not. I think the Lame and Fraunhofer MP3 come out different too. I still mean to pull down some live tracks from Amazon and iTunes to see what they’ve done, and how they play in different players. Amazon uses Lame. iTunes uses Apple.
Just took the same 2min 1644 wav and used the apple droplet to convert to 256kbps AAC. Imported AAC into 16/44 ProTools11 session. The result is a 2:00.550 long file with 550ms of silence padded at the tail only.
If you open that droplet AAC in Wavelab I think you’ll see a different end pad. For one droplet AAC file, I see 115ms end pad if opened in Pro Tools, 70ms end pad if opened in Wavelab, and 20ms end pad if opened in Audacity, so I think the pad depends on the decoder as well as the encoder. At least I seem to remember that from the hydrogenaudio article.
For now, the most seamless way to make files in cases like this might be to encode AAC and MP3 in iTunes, at least for iTunes playback. I would think they’ve probably worked out any inner identification needed to play their own files as seemlessly as possible.