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: No Paddig Flag @insane since Lame V3.95 (Read 3733 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

No Paddig Flag @insane since Lame V3.95

I realised that Lame >V3.95 at "preset insane" has no padding-flag set.
Some decoders - like CEP - don't decode until the last frame, so some samples are missing.
.halverhahn

No Paddig Flag @insane since Lame V3.95

Reply #1 –
Quote
Some decoders - like CEP - don't decode until the last frame, so some samples are missing.

Do you mean that they do not decode at all?
 

No Paddig Flag @insane since Lame V3.95

Reply #2 –
Quote
Quote
Some decoders - like CEP - don't decode until the last frame, so some samples are missing.

Do you mean that they do not decode at all?

No... only the last few samples are missing.
But the filesize at 320kbps is also different, why?

e.g.
Isaac Hayes - Never Can Say Goodbye

filetype - playtime (decoded in CEP) - filesize
------------------------------------------------------------------------------
wav - 3:38.639 - 38.568.140 byte
Lame 3.93.1 @320 (insane) - 3:38.723 - 8.748.929 byte
Lame 3.96 @320 (insane) - 3:38.535 - 8.741.412 byte
Lame 3.93.1 @256 (ap cbr 256) - 3:38.723 - 6.999.143 byte
Lame 3.96 @256 (ap cbr 256) - 3:38.723 - 6.999.143 byte

encode string for CBR 320: --alt-preset insane
encode string for CBR 256: --alt-preset cbr 256

Used encoder:
Lame V3.93.1 from Mitiok's Site
Lame V3.96 from Mitiok's Site

Edit:
The decoded playtime in CEP is different, decoded with F2k all files are the same!
It seems this is a problem in CEP.
.halverhahn

No Paddig Flag @insane since Lame V3.95

Reply #3 –
Quote
But the filesize at 320kbps is also different, why?

Because of padding. When it is used, some frames are one byte longer than those without padding, resulting in different file sizes in your case.

It looks like your decoder uses file size to calculate number of frames, then decodes only that many frames. Without padding, calculated number of frames will be lesser than actual number, so your decoder skips last few frames.

44kHz audio CBR mp3's should always use padding to avoid such problems.

No Paddig Flag @insane since Lame V3.95

Reply #4 –
Quote
Isaac Hayes - Never Can Say Goodbye

filetype - playtime - filesize
------------------------------------------------------------------------------
wav - 3:38.639 - 38.568.140 byte
Lame 3.93.1 @320 (insane) - 3:38.723 - 8.748.929 byte
Lame 3.96 @320 (insane) - 3:38.535 - 8.741.412 byte
Lame 3.93.1 @256 (ap cbr 256) - 3:38.723 - 6.999.143 byte
Lame 3.96 @256 (ap cbr 256) - 3:38.723 - 6.999.143 byte


are versions 3.96, 3.93 and 3.90.3 supposed to give exactly the same results in cbr mode (--api for instance)?

No Paddig Flag @insane since Lame V3.95

Reply #5 –
Quote
are versions 3.96, 3.93 and 3.90.3 supposed to give exactly the same results in cbr mode

Regarding bitrate, yes.
The change here is because of the missing padding in 3.96. (already corrected in CVS)

No Paddig Flag @insane since Lame V3.95

Reply #6 –
Quote
Quote
are versions 3.96, 3.93 and 3.90.3 supposed to give exactly the same results in cbr mode

Regarding bitrate, yes.
The change here is because of the missing padding in 3.96. (already corrected in CVS)


Are there any quality restrictions for the files without padding?
.halverhahn

No Paddig Flag @insane since Lame V3.95

Reply #7 –
btw, might be irrelevant to ask but has --api switch been improved in 3.96?

No Paddig Flag @insane since Lame V3.95

Reply #8 –
Quote
Are there any quality restrictions for the files without padding?

Very minor: 1 byte less in frames without padding.