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: Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002) (Read 7324 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

I think I found a bug in the new compile of LAME (I know, it´s an alpha, so this still can happen).

The bug is as follows: I did by batch-processing convert around 1,200 APE´s (Monkey´s Audio) to MP3 --alt-preset cbr 192 -p with "Monkey´s Audiocompressor".

On some rare cases, the calculation-process stops (meanwhile it was on 2 files), with the error-message

"ResvSize Internal buffer inconistency.flushbits <>",

while the whole DOS-encoding-window is filled with this message. After closing the DOS-window, the encoding of the next file starts without any problems.

- R.A.F. -
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #1 –
Are you able to reproduce this on a specific file?
If this is the case, it would be nice to have a copy of this file somewere on the web or an ftp server.

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #2 –
Please send me the file. LAME 3.94 contains some clean-up arrond bit-reservoir, so the such error may likely to happen (but I cannot find anything as far as I tested).

And tell me what is your LAME more precisely, with what compiler and compiler option you used, et. al.
May the source be with you! // Takehiro TOMINAGA

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #3 –
@ takehiro:
I use the compile-version from this web-page (HA). It´s compiled as far as I know by dibrom. You'll find it on the ftp here.

@ gabriel & takehiro:
Well, fiddling out the 2 files out of these 1,200 isn´t that easy anymore, as it seems that they were saved correctly to hard-disk (but of course with (audible?) bugs in it). But I´ll try my best, to find it out the next days.... I´ll post the search-results here as soon as possible. I will also upload the file, if the error is reproducable again.

The error only appeared in constant-bitrate coding. I coded the same APE-files before with the same codec-version in "--alt-preset standard -p" and no errors appeared at that time.

Nothing more to say at the moment.
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #4 –
Okay, it went faster than thought: I found at least one music-file, which causes these problems. It´s from Kai Tracid and has the title "Too Many Times".

I listened to the MP3-file of it, and after a few seconds (around 5) of playing it leads into silence, and then WinAmp starts to play it from the beginning again. The original APE-file plays until the end (at 3:39 mins) and it´s CRC-checksum is also okay (i tested it by "Monkey´s Audiocompressor).

To the theme "uploading". Well, today it isn´t possible anymore, but for sure I´ll do it the next few days. The APE-version has a length of nearly 27 MB, so I think I will split it up with the RAR-packer and upload both files (the mistaken MP3 has 5 MB) then to a yahoo-briefcase (japan)-account (yes, takehiro, it´s just around the corner from you then ;-)  ). But as I said before: This will take a few days more, as I am not at home tomorrow and past tomorrow.
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #5 –
And well, I nearly forgot: Yes, I was just able to reproduce this error a few minutes ago with the music-file mentioned above. LAME crashed again when trying to generate the MP3-file. So, it´s definitely a bug in it.

- R.A.F. -
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #6 –
And last (now really): The "3.94 a2"-compile made by Dibrom is of course not from 10th of october, it´s from 20th of oct. . Just wanted to say with it, that it´s the latest one, as I downloaded it 2 days ago.
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #7 –
Okay, I´m back again: Finally I uploaded the problem-samples.

You can download the original file in ape-format from here:

Kai Tracid - Too Many Times.ape


... and the generated (mistaken) MP3-file from there:

Kai Tracid - Too Many Times (Mistaken).mp3



Hopefully that helps you to find the bug.


Bye and have a nice search for the little bug says.....

- R.A.F. -


Note: All files are packed with the WinRAR-Packer. So you have to use this one to depack.
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #8 –
Ok, after installing rar and monkeys, finally I reproduce the problem with Dibrom's compile in lame-394-alpha2.zip. --preset cbr 192 and --preset cbr 128, on my windows XP system.

With my compiled version(cygwin + gcc3.1.1, and no nasm), I cannot reproduce it, but another bug is happened (assertion failure in bitstream.c) when I use --preset 128.

It is right there is at least one nasty bug in bitstream or reservoir handling code. I will try to debug it ASAP.

Thank you very much, R.A.F., for your comprehensive tests and the report.
May the source be with you! // Takehiro TOMINAGA

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #9 –
For the record, the compile on this site was made with the default Makefile options "nmake -f Makefile.MSVC" and MSVC7 + ICL6.

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #10 –
"You are welcome", Takehiro. I'm glad to help YOU ALL wherever and whenever I can on this great open-source project.

My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #11 –
why use -p? It's next to useless and detracts from quality.

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #12 –
.... Because the CRC-checksums only use 2 bytes of each frame (with 256 bytes). This means only a very very small quality-degradation of less than 1 % (1/128). So, a 192 kbit-coded music-piece becomes let's say a 190 kbit/s. That's acceptable in my opinion, as there are programs floating around, with which I can check all my MP3's by this checksum in batch-processing. I must admit, that this is only for my personal "security-feeling", as I had some time ago a lot of destructed MPC-files (yes, I know we are talking about MP3 now), and I didn't notice the destruction until I tried to play some of them. And as I don't want that this also happens with my MP3's I did include this checksum-switch, so that from now on mistaken MP3's never go to be undetected again.

- R.A.F. -
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #13 –
Quote
I must admit, that this is only for my personal "security-feeling", as I had some time ago a lot of destructed MPC-files (yes, I know we are talking about MP3 now), and I didn't notice the destruction until I tried to play some of them. And as I don't want that this also happens with my MP3's I did include this checksum-switch, so that from now on mistaken MP3's never go to be undetected again.


A better solution would be to use .sfv or .md5 checksums.

Check this thread and this.

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #14 –
Ok, 3.94alpha4 solves this problem.
May the source be with you! // Takehiro TOMINAGA

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #15 –
could anyone compile this version please ?

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #16 –
Quote
A better solution would be to use .sfv or .md5 checksums.


But sometimes I have to rename some of my MP3's slightly because of spelling-mistakes. Then md5 or sfv reports an error, where no error is. And as far as I know, you can use those checksum-generators only for all of your files at all, which means if you move some of your MP3's out of the current directory to another, those checksum-makers also report an error.

But did you notice? - The last threads are typical "off-topic".

- R.A.F. -
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #17 –
Quote
Ok, 3.94alpha4 solves this problem.


@ takehiro: .... solves which problem?
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #18 –
Quote
@ takehiro: .... solves which problem?

Probably the one you reported yourself:

"ResvSize Internal buffer inconistency.flushbits <>",
 

Bug Found In Lame-codec V3.94 Alpha 2(10-oct-2002)

Reply #19 –
Yes, ofcoz. But outstanding people could have thought something with the CRC-checksums would have been solved....
My used codecs and settings:
FLAC V1.1.2 -4 / APE V3.99 Update 4 -high / MPC V1.15v --q 5 / LAME V3.97b2 -V2 --vbr-new / OGG aoTuV V4.51 Lancer -q5