|
|
| S_O |
| Posted: Jan 21 2003, 07:28 PM |
 |
|
Vdubmod Alpha Testing Team
Group: Vdubmod Alpha Testing Team
Posts: 102
Member No.: 57
Joined: 25-July 02
|
After nekoamp seems to have some bugs, I tested the 100only.mp3 (the big huffman values), to check if it decodes it correctly.
worked, but I noticed the signal was very quiet compared to the output of all other decoders (l3dec, mad, cooledit). First I thought itīs that big-value problem, but I tested a normal file: also too quiet. Then I thought, letīs test with iso-reference streams (sin1k0db.mp3) which should produce a full scaled 1khz sinus-wave. Playing in winamp, wmp etc. worked fine, but muxing didnīt worked. There is 214 bytes of crap at the beginning, I cut it off, it could still be played and now also muxed with tmpgenc. Also the final mpg with video could be played perfectly in wmp, but virtualdub says "Not enough data to decode frame". This happens in the original VirtualDub 1.4.13, in the vbr-fixed and in the mpeg2-version.
This too-quiet bug only affects the nekoamp-versions which has been corrected for layer1. While layer1 is correct now and too load anymore, everything else is now too quiet. |
|
| phaeron |
| Posted: Jan 22 2003, 04:08 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
NekoAmp 1.3 (1.4?) has at least one known bug in MP3 decoding: it swaps samples in the count1 region. I confirmed this against the dist10 decoder. I would not be surprised if it had many more decoding bugs. At the time, I measured compliance with the ear test.
NekoAmp 2.0 is finished and will go out with the next release -- it has a rewritten MP3 core that I actually understand, and which has been checked against the reference decoder at PCM absolute error level for a few dozen streams.
|
|
| fccHandler |
| Posted: Jan 22 2003, 04:54 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
@phaeron: wonderful news!
I had to confirm for myself that sin1k0db.mp3 is indeed broken, but I counted 215 bytes of "crap" rather than S_O's 214 (they are actually remnants of an incomplete first frame). Clipping off those bytes and muxing into an MPEG system with TMPGEnc produces the "not enough data" error which S_O described. Will the new NekoAmp fix this?
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Jan 22 2003, 08:42 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
The reference MP3 decoder doesn't like this stream:
| CODE |
{ 0}Not enough main data to decode frame 0. Frame discarded.
{ 1}Not enough main data to decode frame 1. Frame discarded.
|
The first complete frame in that file has a main_data_begin value of 461, meaning that the frame starts 461 bytes behind in the bit reservoir. Problem is, there isn't 461 bytes in the reservoir at that point. Dropping frames is not reasonable when synchronizing audio to video; 11172-3 doesn't say either way whether having too few bits in the reservoir is an error or not, nor does it prescribe an error concealment method when errors do occur. I'm inclined to say that this stream is actually illegal, but have no evidence either way. I have definitely never seen this from either LAME or the Fraunhofer encoder(s). 11172-3 is underspecified in a number of ways -- it also neglects to mention the way frequency lines are handled above the last scalefactor band, as well as whether big values can exceed 8191 (the famous WinAmp decoder bug).
In any case, NekoAmp certainly can't decode the first two frames in the stream, and my policy in general is to report errors to the user rather than stuffing garbage in the output. Providing a way to report such errors non-fatally is on the todo pile.
|
|
| fccHandler |
| Posted: Jan 22 2003, 09:30 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (phaeron @ Jan 22 2003, 04:42 AM) | | ... my policy in general is to report errors to the user rather than stuffing garbage in the output. |
I agree that is a noble policy, but remember the old saying, "garbage in, garbage out." Speaking as a user, I would prefer to be served a few frames of garbage than to receive a fatal error from which there is no recovery.
--------------------
May the FOURCC be with you... |
|
