RE: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-19 Thread Wai Liu
Hi Alex,

Thanks.  What is the current status of "HIP" ?  Layer I,II,III decoding working okay?

BTW: Greg, thanks for pointing out that mpg123 is not GPL.  I was thrown somewhat by 
the fact that mpglib has made its way into many open-source projects, and that mpglib 
was then relicensed as LGPL.
"18. May. 2001  I changed the license of the 'mpglib' part. It's now under LGPL "

Cheers
Simon


> mpg123 is GPL
> mpglib is LGPL - the version Lame uses is LGPL, with patches to enable 
> Layer I and II decoding.

mpglib which lame uses is GPL. We have a mpglib in a seperate tree
(read: not in the distributed lame versions) which is LGPLed. When we
merge this version of mpglib into lame, we have a 100% LGPL lame.

___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder



Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-19 Thread Greg Wooledge
ruffnex ([EMAIL PROTECTED]) wrote:

> Please confirm if the following is correct... thanks...

> mpg123 is GPL

This is false.  mpg123 is not Free Software, at least according to
the Debian Free Software Guidelines.  The actual license contains
the following text:

   This software may be distributed freely, provided that it is
   distributed in its entirety, without modifications, and with
   the original copyright notice and license included.

The "without modifications" part is what makes it non-free.  This
is also incompatible with the GPL, of course.

-- 
Greg Wooledge  |   "Truth belongs to everybody."
[EMAIL PROTECTED]  |- The Red Hot Chili Peppers
http://wooledge.org/~greg/ |



msg01551/pgp0.pgp
Description: PGP signature


Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-19 Thread Alexander Leidinger
On Sun, 19 Jan 2003 13:30:21 +0800
ruffnex <[EMAIL PROTECTED]> wrote:

> Lame is 100% LGPL.

No. You have to disable the decoder for this.

> mpg123 is GPL
> mpglib is LGPL - the version Lame uses is LGPL, with patches to enable 
> Layer I and II decoding.

mpglib which lame uses is GPL. We have a mpglib in a seperate tree
(read: not in the distributed lame versions) which is LGPLed. When we
merge this version of mpglib into lame, we have a 100% LGPL lame.

Bye,
Alexander.

-- 
Yes, I've heard of "decaf." What's your point?

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder



Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-18 Thread ruffnex
Hi Alex,
Please confirm if the following is correct... thanks...

Lame is 100% LGPL.
mpg123 is GPL
mpglib is LGPL - the version Lame uses is LGPL, with patches to enable 
Layer I and II decoding.

Thanks,
Simon


mpg123 != mpglib (we use mpglib in lame), even if mpglib comes with
mpg123.

Bye,
Alexander.


___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder



Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-13 Thread Martin Hairer
mpg123 != mpglib (we use mpglib in lame), even if mpglib comes with
mpg123.


OK, I see, thanks a lot!

Martin

___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder



Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-12 Thread Alexander Leidinger
On Sat, 11 Jan 2003 17:19:10 +
Martin Hairer <[EMAIL PROTECTED]> wrote:

> > I understand what is happening. The problem is not the ID3V2 tag. The
> > problem is that after this tag, there is some data that is including 
> > some
> > false syncwords. Mpglib is trying to decode it, then fails.
> 
> Funny thing is that I've compiled mpg123, and this seems to work. I 
> thought
> the LAME decoder was the same as the one used by mpg123. Isn't this 
> true?

mpg123 != mpglib (we use mpglib in lame), even if mpglib comes with
mpg123.

Bye,
Alexander.

-- 
 The computer revolution is over. The computers won.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder



Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-11 Thread Martin Hairer
I understand what is happening. The problem is not the ID3V2 tag. The
problem is that after this tag, there is some data that is including 
some
false syncwords. Mpglib is trying to decode it, then fails.

Funny thing is that I've compiled mpg123, and this seems to work. I 
thought
the LAME decoder was the same as the one used by mpg123. Isn't this 
true?
Regards,

Martin

___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder


Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-11 Thread Gabriel Bouvigne
> where Chris.mp3 is the file available at
> ,
> I get the following output:
>
> input:  /Users/hairer/Desktop/Chris.mp3
>  (32 kHz, 1 channel, MPEG-1 Layer III)
> output: /Users/hairer/Desktop/Chris.wav  (16 bit, Microsoft WAVE)
> skipping initial 1105 samples (encoder+decoder delay)
> [A few lines of similar output are skipped here...]
>
> Segmentation fault
>
> Then, lame crashes... The funny thing is that this Mp3 files plays fine
> on iTunes
> and on Mint, two players on MacOS X. Does anyone have an idea of what's
> happening?


Also crashed WMP...
I understand what is happening. The problem is not the ID3V2 tag. The
problem is that after this tag, there is some data that is including some
false syncwords. Mpglib is trying to decode it, then fails.
On debugging, I can see that mpglib is on each failure trying to resync and
decode again (it's heavily switching between channel, sampling rate, and
even layer configurations)

The real mp3 start is at 6F1 from the beginning.

I have a potential solution: when the initial potential sync word is found,
do not try decoding. Instead, try looking if there is a sync word at the
presumed position of the next frame.
If there is, then start decoding, if there is no, then skip byte and try to
sync again.

Unfortunately it's unlikely that I will correct this myself. If womeone is
willing to do it...

Regards,



Gabriel Bouvigne
www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org


___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder



Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-11 Thread Martin Hairer
M> When I call lame --decode Chris.mp3 Chris.wav

M> where Chris.mp3 is the file available at
M> , I get the
M> following output:

	:

M> Segmentation fault

It because Chris.mp3 seems have an ID3 tag and lame does not support 
it.

Same thing happens if I remove the ID3 tag first...

Martin

___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder



Re: [MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-10 Thread Takehiro Tominaga
> "M" == Martin Hairer <[EMAIL PROTECTED]> writes:

M> When I call lame --decode Chris.mp3 Chris.wav

M> where Chris.mp3 is the file available at
M> , I get the
M> following output:

:

M> Segmentation fault

It because Chris.mp3 seems have an ID3 tag and lame does not support it.
-- 
Takehiro TOMINAGA // may the source be with you!
___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder



[MP3 ENCODER] Problems decoding an Mp3 file...

2003-01-08 Thread Martin Hairer
Hi,

When I call

lame --decode Chris.mp3 Chris.wav

where Chris.mp3 is the file available at 
,
I get the following output:

input:  /Users/hairer/Desktop/Chris.mp3
(32 kHz, 1 channel, MPEG-1 Layer III)
output: /Users/hairer/Desktop/Chris.wav  (16 bit, Microsoft WAVE)
skipping initial 1105 samples (encoder+decoder delay)
Frame# 1/16263   99 kbps bitstream problem: resyncing...
Frame# 2/16263  291 kbps bitstream problem: resyncing...
Frame# 3/16263   67 kbps bitstream problem: resyncing...
Frame# 4/16263  416 kbps bitstream problem: resyncing...
Frame# 5/16263  192 kbps bitstream problem: resyncing...
Error: sample frequency has changed in MP3 file - not supported
Frame# 6/16263  161 kbps bitstream problem: resyncing...
Error: sample frequency has changed in MP3 file - not supported
Frame# 7/16263  177 kbps bitstream problem: resyncing...
Error: sample frequency has changed in MP3 file - not supported
Frame# 8/16263   57 kbps bitstream problem: resyncing...
Error: sample frequency has changed in MP3 file - not supported
Frame# 9/16263  256 kbps bitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
Error: sample frequency has changed in MP3 file - not supported
Frame#10/16263   66 kbps  L  R  ibitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
Error: sample frequency has changed in MP3 file - not supported
Frame#11/16263  258 kbps  LMSR  Ibitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
Error: sample frequency has changed in MP3 file - not supported
Frame#12/16263   96 kbps   MS   Ibitstream problem: resyncing...
Error: number of channels has changed in MP3 file - not supported
Error: sample frequency has changed in MP3 file - not supported

[A few lines of similar output are skipped here...]

Error: number of channels has changed in MP3 file - not supported
Error: sample frequency has changed in MP3 file - not supported
Frame#32/16263  599 kbps fatal error.  MAXFRAMESIZE not 
large enough.
Segmentation fault

Then, lame crashes... The funny thing is that this Mp3 files plays fine 
on iTunes
and on Mint, two players on MacOS X. Does anyone have an idea of what's 
happening?
Thanks,

Martin

PS: The same thing happens whether I use version 3.91 or 3.93.1.

___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder