Lame VBR to LAME CBR; Less frames, Shorter Time?!? Options

[TheDogInBackyard]

Hello guys,

Years ago i turned my cds to mp3, mostly in VBR. Now I'm cleaning my collection and re-doing the mp3s with 128kbps using the last version of lame. Tested the lame.exe and tested other apps thats uses lame. The result is always mp3s with a second shorter and less frames. I'm skipping something here? If you do a recode with 100 frames, you have an output with 100 frames? I'm wrong? And the output files is always using a lower values for replaygain... odd too...

Off-topic:
It's ok to use lame 64bit or it's better to stick with the safer 32bit?

Thanks.

[BFG]

Many applications have an option to delete the leading and trailing silent blocks. Do you have that enabled?

[TheDogInBackyard]

It's not that... I know these options... Don't use any kind of modifications in audio enconding... not even replaygain... only the old good -b 128 --cbr and the defaults from lame...

This post has been edited by TheDogInBackyard: Jan 19 2013, 03:04

[db1989]

The result is always mp3s with a second shorter and less frames.

As measured by what?

And the output files is always using a lower values for replaygain... odd too...

Exactly how many “Years ago” were your old files encoded? ReplayGain has changed in implementation over time, so that may explain this observation.

I hope you see the need for more specificity if anyone is to make useful guesses at the causes, here.

Edit: Wait, are you feeding LAME its old files and having it re-encode them, rather than ripping anew from CD? As well as being very likely to explain the change in size and ReplayGain, that is a very bad idea.

This post has been edited by db1989: Jan 19 2013, 03:17

[TheDogInBackyard]

For "tag" replaygain in mp3s and other audio files I always use foobar. My entire collection have replaygain from a very old version of foobar. From my tests today in re-encoding, I re-scanned some mp3s with replaygain, and again after re-enconding.

A mp3 I just re-encoded right now:
Original file: VBR / Track Gain -6.920000 Album Gain -5.480000 / 3:31.278 (9 317 376 samples)
Re-encoded with foobar and lame 3.99.5 64bit from videohelp.com (no use of replaygain to re-encode)
Output file: CBR / Track Gain -6.490000 Album Gain -5.050000 / 3:31.097 (9 309 359 samples) (Some files lose less samples other lose more and one second of audio)

Re-encoding mp3 and losing some quality can explain the change in replaygain... I think...

I'm not re-encoding all my collection, just part of it, a part less important. I know about the loss of some quality in re-enconding in lossy formats. I read these forums over some year now. The concern is to damage the audio from files and have to re-rip lots of cds or start to listen "clicks" between musics.

This post has been edited by db1989: Jan 19 2013, 04:30

Reason for edit: deleting unnecessary full quote

[db1989]

For "tag" replaygain in mp3s and other audio files I always use foobar. My entire collection have replaygain from a very old version of foobar. […] Re-encoding mp3 and losing some quality can explain the change in replaygain... I think...

Right, re-encoding might well produce some differences, but probably more significant is the fact that foobar2000 now uses r128gain, which is a levelling algorithm similar to ReplayGain but better weighted for perceptual loudness. Again, if you’d mentioned things like this to begin with…

As for the loss of samples, do your original files have delay and padding tags? That’s the only possible cause that I can think of, although others may know more.

[TheDogInBackyard]

I don't really known what delay and padding attributes are for... but...

From left to right:

1st properties: Free Song download from net. Made with newer encoder. With Delay and padding.
2nd properties: Re-encode of the original 1st. Same number of frames. Same time. Same delay. But the padding was changed.
3rd properties: Very old mp3 from my rippings in the good old days. The old encoder don't produced the delay and padding values.
4th properties: Re-encode from 3rd. Different frames, time. And now there are delay and padding.

Any idea?

[lvqcl]

Install foo_verifier and test the 3rd file.

[TheDogInBackyard]

All fine with foo verifier. Status ok and none warnings.

[db1989]

I’ll ask again since this is another thing that you haven’t specified and have left us to guess through implications at best: Are you encoding by sending MP3s directly into LAME itself, or are you encoding via a front-end that does its own decoding first, such as foobar2000? LAME’s decoder is not particularly fully featured, so I can believe that it does not treat even its own delay/padding information correctly.

[greynol]

Lame has honored gapless decoding for several years now.

[TheDogInBackyard]

Made some tests this morning... found the problem... very old "buggy" encoders and old apps using lame.... -> wrong header... -> even latest lame can't handle mp3 with wrong header correctly...

Used in test:
1. Lame 3.99.5
2. Lame 3.99.5 64bit
3. Easy CD-DA Extractor v16
4. EZ CD Extractor v1
5. BeSweet with the original lame from ages ago
6. BeSweet with new lame.dll from 3.99.5
7. latest foobar with lame 3.99.5

[mjb2006]

Here are some things to think about, things which affect the sample counts (sorry if you know this already):

• The MP3 encoder adds junk samples to the beginning (encoder delay) and end (padding) of the MP3. This happens every time you encode.
• The MP3 decoder adds even more junk samples to the beginning (decoder delay), and lags behind its input, so the same # of samples at the end will be unreachable—hence the need for padding.
• The delay is consistent for each encoder, but padding varies with the length of the input and various esoteric factors.
• VBR files encoded by LAME (3.12 and up) should have a VBR header (contains the string "XING"). CBR files encoded by LAME (3.94 and up) should also have a VBR header (contains the string "Info").
• Info about the encoder delay & padding can be stored in the LAME tag (3.90 and up), which is embedded in the VBR header. A player can use the info to trim the junk samples from each end of the decoder's output.
• If you use foobar2000 to "fix" a CBR file that has no VBR header, it will add a header with a fake LAME tag saying 0 padding and 0 delay, which is probably wrong.
• Many players don't honor the LAME delay & padding values, and trim nothing, or just trim the decoder delay. Those that do trim encoder delay & padding, like foobar2000, usually don't handle low padding values as well as they could.

If you need to convert VBR to CBR, or vice-versa, it can be done without loss using MP3packer.