Hi,
I think the app is probabry violating LGPL of mpglib, but I wonder
it violates that of LAME... very suspectable, but I cannot assert.
Anyone used the software and check the output mp3 file ?
I think we can say "violate or not" from it.
From: Spire Spire <[EMAIL PROTECTED]>
Subject: [mp3encoder] possible lame LGPL violation
Date: Sat, 6 Dec 2003 17:32:43 -0800 (PST)
> I was able to find the byte sequences from the static
> const unsigned char rv_tbl[] array from
> lame/libmp3lame/fft.c in their exe (Flicker.exe
> 1.0.0.1). (using Cygwin od/grep/strings tools)
The values are simple bit-reversed numbers.
They are common for all the FFT/FHT code and I think it is not
sufficient evidence.
> The static const unsigned char slen[] in
> III_get_scale_factors_1() in lame/mpglib/layer3.c also
> appears.
:
> And static const short t24HB[] in
> lame/libmp3lame/tables.c
They are also common for all MP3 encoders/decoders.
> Also some string constants from
> lame/mpglib/interface.c and lame/mpglib/layer3.c:
>
> C:\Program Files\ImageMatics>strings Flicker.exe |grep mpg
>
> mpglib: wordpointer trashed. size=%i (%i) bytes=%i
> mpg123: Can't rewind stream by %d bits!
WOW, mpglib is LGPL and they are sufficient evidence.
> And from lame/mpglib/interface.c:
>
> C:\Program Files\ImageMatics>strings Flicker.exe |grep bitstream
>
> bitstream problem: resyncing...
HEHE, maybe this is from LAME, but these words are common for
many application.
And I found the below string in the binary,
"fatal error. MAXFRAMESIZE not large enough."
This is in the lame/libmp3lame/bitstream.c, but they are also common
strings, I afraid.
--
Takehiro TOMINAGA // may the source be with you!
_______________________________________________
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
