[SVN-1.0] You got some really nasty file there...

Logged In: YES
user_id=470743
Originator: NO

Hm, that could take a moment longer than the id3 fix.
Comparing the errors that 0.59r gives with the buddha-like silence of 0.59s raises the suspection that there is indeed some functional change in the decoder that I need to backport.
Too bad that you don't see the functional changes at first glance as there are also structural changes.

Question is still if the file is valid mp3 or if 0.59s is just very generous...

plot of first channel from pre0.59s and svn (to-be 0.65)

Logged In: YES
user_id=470743
Originator: NO

File Added: nasty.png

Logged In: YES
user_id=470743
Originator: NO

current svn skips 13 frames because of the check, 0.59r does not produce _any_ output, because of errors.
So we improved, but there is room left.

Logged In: YES
user_id=470743
Originator: NO

If I remove the concerning check, the svn version decodes every frame. But that check is there or a reason: You can produce files (in malicious intent) that crash the decoder without it.
So I wonder if these files are really good.
Can you re-encode the original source with a newer lame, trying to use the same settings, and see if the resulting files are more "nice"?
Perhaps one should browse lame's history to see if there was a bug about this.
Or one has to really dig the spec and grok the algorithm in detail to discover who's right. I still have to get deeper into layer3.c ...

Logged In: YES
user_id=1697853
Originator: YES

Unfortunately, I do not remember all the settings I was using in the summer of 2001 :)

I believe I was running mandrake 8 and probably used default settings except to turn VBR on. From the xing frame I see it was lame 3.70 April 6 2000. As suggested by you, I had a look at lame's change history and I think xing vbr headers had just been introduced not long before 3.70.

I found this change in 3.86beta August 6 2000:
-setting appropriate CRC bit for additional Xing-VBR tagging frame

So that was for the other problem you fixed ([ 1629697 ] vbr+stereo+noprot -> error: big_values too large!)

Not really sure what to look for in the change log to know if they fixed the "nasty" problem so I took the next available archived source, LAME 3.88beta March 25 2001, and reencoded one of the problem songs with this version using only the -v (vbr) option.

I played the mp3 with mpg123 0.62 and there is no "big_values too large" and no "nasty" -no problems at all.

Between 3.70 and 3.88 was a very busy 7 months for lame with many new features and bug fixes. I see a few items in the change log that are for fixing encoding bugs but really don't know if they are related to the problem in this bug report.

Maybe this?:
Bug fix: M/S switching at lower sample rates (the fact there is no 2nd granule was ignored)

So it appears this problem is limited to a relatively short interval of lame versions. Unfortunately, 3.70 was the stable release from April 2000 until 3.90 in Dec 2001 if I read the history right.

Anyway, with the current svn, these files play well enough for my ears. As I've said, the errors come out during fade-in/fade-out so maybe it is at a practically silent time the frames are discarded.

Maybe you could check out the history between the versions above and see if any changes seem related to this issue. It is here: http://lame.cvs.sourceforge.net/\*checkout*/lame/lame/doc/html/history.html?revision=HEAD

Logged In: YES
user_id=470743
Originator: NO

Wow, thanks for the investigation.
Also for me it is difficult to judge what encoder bug fix specifically affects this "nasty" check, as I am yet no Master of the Full Understanding of the Decoder Code.
But your pick indeed sounds sensible... perhaps one could handle the case with ignoring one of the regions... I will have a look at the lame history, too, and perhaps query the lame mailing list - but I am not too confident that someone there will recall anything useful after the years.

We'll see when this bug is closed for good, but I think I should do the 0.65 release this night with what we achieved so far.

Thanks for your active help on this.

Logged In: YES
user_id=470743
Originator: NO

Hm, I guess this can be closed, then... we play the file well enough and there is encoder weirdness involved.

I'll close the bug once we got 1.0 out (with a whole lot of other bugs;-).
Agree?

Logged In: YES
user_id=1697853
Originator: YES

Yes I agree. It is dealing with those files well enough for me.
Thanks. Looking forward to 1.0

A post mortem note on this:

------------------------------------------------------------------------
r1390 | thor | 2008-03-01 11:14:05 +0100 (Sat, 01 Mar 2008) | 2 lines

The "r0c/r1c > 22 fix" from mhipp rev 51.

------------------------------------------------------------------------

There was a real fix for this, imported into the new mpg123 with revision 1390. Recently, the "nasty file" hack has been removed, as it was turned into dead code by the above change.