Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-04 Thread Frank Klemm

::  
::  ISO spec says the maximum should be 8191.  But as part of huffman
::  decoding, you sometimes add 15 to the result, yielding values as large
::  as 8206.  Right now, LAME (and the ISO dist10 code) will make use of
::  the full range: values up to 8206. 
::  
::  The question is, should LAME be modified to limit this range to 8191.
::  
How likely is it that music triggers this error?

When it is very unlikely in music, I would fix it in Lame.

Rationale:
  * unlikely in music means that it is very unlikely to improve
music' quality by using factor from 1FFF to 200E.
  * unlikely in music also means that it is not (urgent) necessary
to fic this bug in WinAmp to play correctly older lame encoded
files

Does it decrease performance to make this command line configurable?

-- 
Mit freundlichen Grüßen
Frank Klemm
 
eMail | [EMAIL PROTECTED]   home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany

--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )



Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-03 Thread Youri Pepplinkhuizen




Great! Just one thing - does the fact big_values 
is limited to 8192 now mean a loss of quality?

Imposing a maximum value of 8191 is a completely unneeded restriction 
which results in a (very tiny) loss of quality.

I don't get this, since apparantly, it is a needed 
restriction. Or is it like this: dist10 uses 8206 after adding 15 to big_values and LAME used to add 15 to 8206? I'm 
confused. Does this mean LAME complies to the ISO spec now or was the ISO spec 
incorrectly specified?

-Youri


Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-03 Thread Mark Taylor

 X-Authentication-Warning: geek.rcc.se: majordom set sender to 
[EMAIL PROTECTED] using -f
 From: "Youri Pepplinkhuizen" [EMAIL PROTECTED]
 Date: Tue, 3 Oct 2000 09:22:08 +0200
 Content-Type: multipart/alternative;
   boundary="=_NextPart_000_0022_01C02D1B.673EA6E0"
 X-Priority: 3
 X-MSMail-Priority: Normal
 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
 Sender: [EMAIL PROTECTED]
 Precedence: bulk
 Reply-To: [EMAIL PROTECTED]
 
 Great! Just one thing - does the fact big_values is limited to 8192
 now mean a loss of quality?
 
 Imposing a maximum value of 8191 is a completely unneeded
 restriction which results in a (very tiny) loss of quality.
 
 I don't get this, since apparantly, it is a needed restriction. Or
 is it like this: dist10 uses 8206 after adding 15 to big_values and
 LAME used to add 15 to 8206? I'm confused. Does this mean LAME
 complies to the ISO spec now or was the ISO spec incorrectly
 specified?
 
 -Youri

ISO spec says the maximum should be 8191.  But as part of huffman
decoding, you sometimes add 15 to the result, yielding values as large
as 8206.  Right now, LAME (and the ISO dist10 code) will make use of
the full range: values up to 8206. 

The question is, should LAME be modified to limit this range to 8191.

Mark


--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )



Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-03 Thread Youri Pepplinkhuizen

Hmmm, nah I don't think it should. If even the ISO source uses 8206, why
change it when the Nitrane bug has already been fixed by Nullsoft? Also, how
come only Nitrane is triggered by this setting? All other decoders work
fine. It would seem like it, that using a value of 8191 is more of a
'workaround' to the Nitrane bug, but the actual bug is still present. Since
Nullsoft said they fixed it now, I don't think LAME has to lose quality just
to help out users of older versions of Winamp.

Just my opinion, I could be wrong. :)

-Youri

--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )



RE: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-03 Thread alex . broadhead

Howdy,

 ISO spec says the maximum should be 8191.  But as part of huffman
 decoding, you sometimes add 15 to the result, yielding values as large
 as 8206.  Right now, LAME (and the ISO dist10 code) will make use of
 the full range: values up to 8206.

 The question is, should LAME be modified to limit this range to 8191.

I'm not sure the ISO spec actually explicitly gives a maximum value; the
limit can be inferred from the Huffman code tables, though.  The largest
value possible is obtained in table 31, which uses 15 as an escape value to
signify the addition of 13 linbits:  2^13 - 1 + 15 = 8206.  The dist10 code
manages to screw this computation up, however - it uses 8191 + 14, an
off-by-one error.  Doh!

As for decoders, the ISO decoder has no built in limits - it will traverse
the tables and read the proper amount of linbits.  Winamp must be explicitly
checking for overflow, which, if you have properly implemented Huffman
decoding, should never be possible.  (And since you can exhaustively test
the tables, it should be relatively easy to verify your Huffman decoder.)

Alex

--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )



Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-02 Thread Naoki Shibata


Naoki IIRC, bug of winamp is also triggered by FhG encoded mp3 file.

  This means that nitrane has more than one bug.
  So, changing IXMAX_VAL to 8191 doesn't solve all problems.

  I think we should investigate what FhG encoder does, and make lame do
what FhG does.

--
Naoki Shibata   e-mail: [EMAIL PROTECTED]

--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )



Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-02 Thread Mark Taylor

 X-Authentication-Warning: geek.rcc.se: majordom set sender to 
[EMAIL PROTECTED] using -f
 Date: Mon, 02 Oct 2000 18:32:58 +0900
 From: Naoki Shibata [EMAIL PROTECTED]
 Content-Type: text/plain; charset=US-ASCII
 Sender: [EMAIL PROTECTED]
 Precedence: bulk
 Reply-To: [EMAIL PROTECTED]
 
 
 Mark It is possible to encode values up to 8206, although the ISO docs can
 Mark be interpreted to say you should not use values greater than 8191.
 Mark Most decoders can handle values up to 8206, including Fraunhofer, but
 Mark some decoders (Winamp, Macamp, Sonique) choke on this.  
 Mark This probably shouldn't be called a winamp bug or a LAME bug,
 Mark but instead a unclear ISO specification.
 Mark 
 Mark Should we change IXMAX_VAL to 8191? 
 
   IIRC, bug of winamp is also triggered by FhG encoded mp3 file.
   And, Null soft have already almost completed their new decoder.
 
 

The 100hz bug is not triggered by FhG produced mp3 files.

But winamp does have some other, less audible problems, as shown by 
David Robinson's web site.

Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )



Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-02 Thread Gabriel Bouvigne

 Should we change IXMAX_VAL to 8191?

 pros:
 1. as Rob points out, less false syncwords in the bitstream.
(8206 is encoded as 0x1FFF).
 2.  LAME produced mp3's will no longer trigger Winamp bug.

 cons:
 1. Winamp may not bother to fix their decoder
 2. Tiny loss in quality just to pander to Winamp users.
(all Linux decoders I've tested do not have this problem)
 3. LAME produced mp3's will no longer trigger Winamp bug
(so it will look like it was a bug in LAME :-)

I'd vote for limiting it to 8205. The quality loss would be very minimal. It
won't solve winamp's problem, but it's easy to fix in the decoder, now that
we know exactly what the problem is.
The advantage is that 8205 is 0x1FFE, which is not a valid syncword for
mpeg1-2. With this, audio resync on corrupted bitstreams would be easier for
the decoder


Regards,


--

Gabriel Bouvigne - France
[EMAIL PROTECTED]
mobile phone: [EMAIL PROTECTED]
icq: 12138873

MP3' Tech: www.mp3-tech.org


--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )



Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

2000-10-02 Thread Mark Taylor



For decoder enthusiasts: 100hz bug fixed versions of Nitrane and their
upcoming Nitrane replacement are available at:

http://www.sulaco.org/mp3/winamp/winamp.html

Nullsoft sent me these .zip files, but I haven't tested them
yet.  They are probably also available somewhere on www.winamp.com.

Mark




--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )