> > 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 t
Hello,
new alpha winamp plugin was released
http://www.landoleet.org/~deadbeef/in_mp3_260_alpha13.zip
http://www.chat.ru/~dkutsanov/in_mp3_260_alpha13.zip
Changes:
* [a13] 8191 bugfix.
8)))
Best regards,
Dmitry mail to: [EMAIL PROTECTED]
--
MP3 ENCODER maili
Gabriel Bouvigne schrieb am Mon, 02 Okt 2000:
> > 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 no
::
:: 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 LA
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 modif
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
'workar
> 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
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
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.
M
> 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
> 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]
>
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:
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> Thi
I was going through my backlog of email that still needs to be
answered, and I came upon Rob's Jun 21 message (below) about the
maximum value of the big_values range. As I read this message for the
third time, still not sure what to think about this issue, it occured
to me: This has to be the wi
14 matches
Mail list logo
