Re: [MP3 ENCODER] lame 3.80 beta
Mark wrote: If no problems show up with 3.80, then in a few weeks I think we should make another official release, and finally drop all the dist10 patching stuff! I think it's great that this could be done, but there must be something I've missed. My understanding is that a licence would probably be required to keep this project out of trouble if the patching was removed Lame really became an MP3 encoder. Wouldn't that defeat one of the main purposes of this project? If it goes to licencing, I guess the question must be raised- how much should have to be paid as insurance (against scratched CDs LPs, chewed tapes) convenience (of being able to stream audio such as interviews, into a format much less clumsy than audio tape or PCM waveformats) ? And how would this charge be applied to LAME? Shawn PS- Would the name have to be changed to something like "LIFAME"? (Lame Is Finally An Mp3 Encoder) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Mp3 encoders quality tests
On the site you recommend WinAMP for the listening, while just recently a winamp bug was discussed on this list, which add corruptions during playback of mp3s ! The bug is present in winamp 2.62 ( latest as of this writing ), as reported on this list. david balazic George wrote: Hi to everyone! Just to say We've started the Mp3 Quality Tests. To continue the project We need volunteers to make auditions of Wav Mp3 files. If you're interested or know someone can be interested in, please go to http://www.hispamp3.com/bench/inde.htm or http://benchs.emp3.com . Everyone is welcomed. Thanks to all George "Mp3 Encoders Quality + Speed Stats" http://benchs.emp3.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Continuation of crippling wavs
If you remember my question a while ago about crippling wavs so they sound bad at all but the highest bitrates, this is a follow-up. My band is recording its album in the near future. I know MP3 has its limitations, I thought it would be useful for the band from a business perspective if we messed with the original recorded tracks to make so-called "CD-quality" MP3ing difficult. The recorded tracks will probably consist of the following (maybe less, but no more)- 2 tracks for the kick drum (front back) 2 tracks for the snare (top bottom) 4 tracks for the toms (4 toms- one track for each) 1 track for the hi-hat 2 overhead mics (for the cymbals room resonance) 4 tracks for the guitar (2x stereo) 1 or 2 tracks for the bass guitar (1x mono or stereo) up to 4 tracks for vocals (1x stereo lead, up to 2 backups) up to 4 tracks for keyboards (2x stereo) up to 4 tracks for solo instruments (more if we get carried away hire a 96-piece orchestra :-) The album will be a mix of ballads rock songs. How do you guys suggest we do it? Note that we'd like there to have no percievable difference between the original effected sound in the studio. I decided that the MP3 encoding should be bad for the following combinations- 128kBit/sec - JStereo - 44.1kHz 112kBit/sec - JStereo - 44.1kHz 56kBit/sec - JStereo - 22.05kHz I'd like to limit the subectivity of the word, "bad", to mean that it sounds particularly nasty unfaithful to people who are normally satisfied with sound quality at those described bitrates. But I'd like it to still sound perceivably lossless for 320kBit/sec - Stereo, 'cause *I* would like to be able to make an MP3 of our stuff w/o having artifacts popping out everywhere. But that doesn't really matter quite so much 'cause I could always get a copy of the CD, mastered without the mangling. Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Mp3 encoders quality tests
David wrote- On the site you recommend WinAMP for the listening, while just recently a winamp bug was discussed on this list, which add corruptions during playback of mp3s ! The bug is present in winamp 2.62 ( latest as of this writing ), as reported on this list. Can anyone say whether it would be wise to use an earlier version of Nitrane's decoder (distributed w/ Winamp version 2.1-something ) with Winamp ver2.6-something? Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Mp3 encoders quality tests
Shawn Riley wrote: David wrote- On the site you recommend WinAMP for the listening, while just recently a winamp bug was discussed on this list, which add corruptions during playback of mp3s ! The bug is present in winamp 2.62 ( latest as of this writing ), as reported on this list. Can anyone say whether it would be wise to use an earlier version of Nitrane's decoder (distributed w/ Winamp version 2.1-something ) with Winamp ver2.6-something? Shawn Note that some winamp versions ( early 2.x , I think ) didn't use Nitrane , but Faunhofer ! david -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Winamp decoder plugins (Formerly Mp3 encoders quality tests)
Shawn Riley wrote: Can anyone say whether it would be wise to use an earlier version of Nitrane's decoder (distributed w/ Winamp version 2.1-something ) with Winamp ver2.6-something? David wrote: Note that some winamp versions ( early 2.x , I think ) didn't use Nitrane , but Faunhofer ! I'll have see if VerW.XX is compatible with VerY.ZZ out of what I've got. I'm pretty sure I have versions 1.91, 2.06, 2.5e. Let's start an archive of old Winamp MP3 decoder plugins. I'll volunteer those versions. I don't know if it counts, but I only have them for Windoze 95. So oops, guess I didn't check whose engine was included. I haven't used those 2 earlier versions of Winamp for ages. So why would Nullsoft (or whoever it is) abandon Fraunhofer for Nitrane? Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Winamp decoder plugins (Formerly Mp3 encodersquality tests)
haven't used those 2 earlier versions of Winamp for ages. So why would Nullsoft (or whoever it is) abandon Fraunhofer for Nitrane? Nitrane is based heavily on AMP. Or more accurately, it started as AMP. It was supposedly rewritten and nitrane was "better". In any case, Playmedia sued Nullsoft for having AMP code, which they settled out of court just before the AOL buyout. During the time that the lawsuit was filed, and then time they they settled, they stopped using Nitrane and distributed Fhg's decoder in its place. Since Nitrane was "better", they switched back once they suit had been settled. Or maybe that was one of the conditions, was that they MUST use nitrane. Who knows. I don't think details were made public. In any case, that's why they used fraunhofer. Winamp usually claims two things 1) nitrane sounds better 2) nitrane is faster 1 is obviously false, but who knows for 2. i dont' think the fraunhofer decoder was SIGNIFICANTLY slower, although since you guys are comparing versions now, you might find that it is. jack. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.80 beta
LAME (LAME is After all a Mp3 Encoder) I still like LAME (Lame ain't your momma's encoder) jack. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Continuation of crippling wavs
I think your wasting your time Shawn. There have been problems in the past with LAME and other encoders which may have been expoited to make bad sounding MP3's, but as each distortion is isolated, it has also generally been worked on to overcome the distortion. So I suspect your album would become the test case to get LAME working even better. Cheers, Ross. Shawn Riley wrote: If you remember my question a while ago about crippling wavs so they sound bad at all but the highest bitrates, this is a follow-up. My band is recording its album in the near future. I know MP3 has its limitations, I thought it would be useful for the band from a business perspective if we messed with the original recorded tracks to make so-called "CD-quality" MP3ing difficult. The recorded tracks will probably consist of the following (maybe less, but no more)- 2 tracks for the kick drum (front back) 2 tracks for the snare (top bottom) 4 tracks for the toms (4 toms- one track for each) 1 track for the hi-hat 2 overhead mics (for the cymbals room resonance) 4 tracks for the guitar (2x stereo) 1 or 2 tracks for the bass guitar (1x mono or stereo) up to 4 tracks for vocals (1x stereo lead, up to 2 backups) up to 4 tracks for keyboards (2x stereo) up to 4 tracks for solo instruments (more if we get carried away hire a 96-piece orchestra :-) The album will be a mix of ballads rock songs. How do you guys suggest we do it? Note that we'd like there to have no percievable difference between the original effected sound in the studio. I decided that the MP3 encoding should be bad for the following combinations- 128kBit/sec - JStereo - 44.1kHz 112kBit/sec - JStereo - 44.1kHz 56kBit/sec - JStereo - 22.05kHz I'd like to limit the subectivity of the word, "bad", to mean that it sounds particularly nasty unfaithful to people who are normally satisfied with sound quality at those described bitrates. But I'd like it to still sound perceivably lossless for 320kBit/sec - Stereo, 'cause *I* would like to be able to make an MP3 of our stuff w/o having artifacts popping out everywhere. But that doesn't really matter quite so much 'cause I could always get a copy of the CD, mastered without the mangling. Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.80 beta
Christian Schepke wrote: What about the idea with the trial-version of LAME. AFAIK it's allowed to distribute trialversions of mp3-encoders. We could include a little routine that displays a WARNING TRIAL EXPIRED or something alike, when the 30 days are over. That is true BUT, the binary distributor can only produce trial versions with the intent of selling them. Also, there is a minimum annual figure that must be paid to FHG. I forget the amount but it was 5 or 6 digits. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] Hardware reccomendation
Hi Ivo! Woah, that's pretty big difference, isn't it?? YES b) you use an older, slower version of LAME Well, it was based on some older versions, I'm now testing it with the version I have now, which is Lame 3.69. Is there much difference in speed from the newer versions? I can't remember, but I think there is a speed increase from 3.69 to 3.80 But it's still not the 0.61x you got on your 133MHz... I guess that 3.80 CVS is even faster (in CBR)??? c) your compiler does some strange things I have egcs-2.91.66, I have heard some bad stories about egcs, though... Maybe you have compiled the debugging version? You may take a look at the compiler switches in the Makefile. Probably your version is without the assembler optimizations? d) your Pentium runs at half speed What!? :) That seems even less probable and would be pretty stupid :) I think I would have noticed this long before. Besides, how can such a thing be accomplished? You are right, you would have noticed that a long time before :) Ivo Robert -- Sent through GMX FreeMail - http://www.gmx.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Naming
Well, I think the name LAME doesn't need to be changed whatever happenes... Now we know LAME as "LAME Ain't an MP3 Encoder". Dropping the whole ISO code, LAME may become "LAME is An MP3 Encoder". It's LAME either way! What do you say? :-) PS- Would the name have to be changed to something like "LIFAME"? (Lame Is Finally An Mp3 Encoder) What about FAME (Finally An Mp3 Encoder) or in the old tradition of geeks FAME (FAME is a Mp3 Encoder) but perhaps we simply stay with LAME (LAME is After all a Mp3 Encoder) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] free format bitstreams
AFIR you are not allowd to use VBR with free format. However, is that another part of the standard lame can ignore (via option)? It might simplify VBR if we 'threw out' the bir resviour and just used free format frames. On Sat, 6 May 2000, Mark Taylor wrote: Mark Taylor wrote: Latest version of lame, in CVS, should now decode free format bitstreams. Where did you find free format bitstreams to test? Regards, I created them with the new "--freeformat" option in LAME :-) freeamp and "lame --decode" both seem to play them back correctly, but that is the only testing I've done. The ISO spec says that free format bitstreams are limited to 320kbs, but lame will allow you to specify any bitrate over 8kbs. (lame prints warnings when using freeformat) "lame --decode" can handle up to 560kbs, and freeamp can handle up to 440kbs. XMMS cant handle free format. I havent tested any other players. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] Hardware reccomendation
"R" == Robert Hegemann [EMAIL PROTECTED] writes: R I can't remember, but I think there is a speed increase from R 3.69 to 3.80 Yes there is. I made a more fast/efficient huffman coding. but another coding change (for thread safe) vailed it... "I" == Ivo [EMAIL PROTECTED] writes: I Allright, my (hopefully ;)) final word on my Pentium 133MHz bad I MP3 encoding performance... I just compiled the released 3.80 I and it's slower (CBR) than what I just encoded with 3.69, as I you can see below: I Linux shell lame -h track_07.wav If you using Linux 2.2.x, you can check your CPU clock simply by linux shell cat /proc/cpuinfo or, 2.0.x, do the same command and check out bogomips line. CPU clock will be about (bogomipis)/39*100(this is pentium only formula). I it's got an Intel processor (which I think should FPU pretty well?), P54C's FPU is pretty better than the K5,K6,686MX.. with the same CPU clock, but it was too old... its on chip cache is too small. between PentiumPro(including celeron, PII, PII) and normal Pentium, there's about 2x FPU power. K6, 686MX... has more slow FPU. K6-2,III are also, but they have 3DNow! and it'll be fast (maybe about as twice as the same clock Pentium) if someone write the code to use it :p --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame 3.80 Vrb q:
Michael Hare wrote: I've noticed a HUGE reduction in the average bitrate between version 3.70 and 3.80, using VBR with the highest quality setting. I made some tests yesterday and I found that there was a noticeable difference in size between 3.70 VBR and 3.80 VBR. It seems that it works much better now, I had a sample where joint-stereo + VBR was not working very well with LAME 3.70 and now it's solved! By the way, LAME 3.80 puts a lot of "informative message" when encoding (the file is reservoir.c), and I find it a little annoying. Is this information useful? Is there any way to disable it? (apart from commenting the lines in the source code, that is) Will there continue to be big leaps and bounds for smaller file sizes (I can't imagine they could get much smaller using highest quality). I'm curious before I encode any more of my cd's! I was using '-V 4 -m s' before, but since LAME 3.80 solved the joint-stereo problems that I had noticed, now I'm using '-V 2 -m j', which saves a little more space :) = mailto:[EMAIL PROTECTED] -= Alberto Garcia =- http://www.cryogen.com/berto Clave publica PGP disponibleFidonet: 2:348/105.108 __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] Hardware reccomendation
Well, it was based on some older versions, I'm now testing it with the version I have now, which is Lame 3.69. Is there much difference in speed from the newer versions? I can't remember, but I think there is a speed increase from 3.69 to 3.80 Well, I noticed a speed DECREASE in 3.69 - 3.80, actually... but maybe you're right about the Makefile, I always use the default, not changing anything. Perhaps the defaults changed..? I have egcs-2.91.66, I have heard some bad stories about egcs, though... Maybe you have compiled the debugging version? You may take a look at the compiler switches in the Makefile. Probably your version is without the assembler optimizations? I suppose Lame (even beta versions) do not compile in debug mode by default? (i.e. with the Makefile supplied with the downloaded sources) Are the assembler optimizations on by default? Again, I think Takehiro might be right and my memory's performance just sucks... Plus, Pentium is said to do worse than Pentium Pro and better, disregarding clock speed. Ivo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Hardware reccomendation
I am about to upgrade my motherboard and I am looking for suggestions on what the minimum horsepower needed to do = real-time encoding on a AMD or a Cyrix systems. !(Intel inside) What is the encoding process bounded by? I/O operations or computational speed? computational speed On an embedded system with a K6-200 (without L2 cache!) and gogo 2.31 there was still CPU power left for other things. ...which means you are *not* cpu bound. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Hardware reccomendation
Computational speed, and cache size seem to be the most important Cache size and speed are the only important factor if you have cache misses, and you own an Intel processor. Cache misses are _extremely_ expensive. The P166 MMX and up have a better cache than the P133 and down. But my lowly K5-100 beats the P166 hands down. Hey, it doesnt matter if your fmul takes 4 instead of 3 cycles, if the competitor first has to wait 60+ cycles until its data finally arrives... This is why I encode both channels separately in PEM. (i.e., a granule mid channel, a granule side channel, a granule mid, etc.) Oh, by the way, anyone interested in better DCT's? Nou dag dag, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] Hardware reccomendation
R I can't remember, but I think there is a speed increase from R 3.69 to 3.80 Yes there is. I made a more fast/efficient huffman coding. but another coding change (for thread safe) vailed it... Hmmm... I encoded the same song twice, with the same parameters and it was encoded slower with 3.80, but maybe there are some other aspects that slow it down? Maybe encoding it multiple times and taking an average would reveal a more trustworthy result. If you using Linux 2.2.x, you can check your CPU clock simply by linux shell cat /proc/cpuinfo or, 2.0.x, do the same command and check out bogomips line. CPU clock will be about (bogomipis)/39*100(this is pentium only formula). 53.04/39*100 = 136, so that's about right, I'd say ;) I it's got an Intel processor (which I think should FPU pretty well?), P54C's FPU is pretty better than the K5,K6,686MX.. with the same CPU clock, but it was too old... its on chip cache is too small. between PentiumPro(including celeron, PII, PII) and normal Pentium, there's about 2x FPU power. K6, 686MX... has more slow FPU. K6-2,III are also, but they have 3DNow! and it'll be fast (maybe about as twice as the same clock Pentium) if someone write the code to use it :p Right, that puts us back into the topic this thread followed before much interferance from me ;) This is pretty helpful in choosing a new computer that will perform well with encoding MP3's. And I do need a new computer :) (P133... *sighs*) Ivo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Hardware reccomendation
Segher Oh, by the way, anyone interested in better DCT's? I made faster mdct_long and sent it to Takehiro. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] 3.80: Build problems w/NT
I tried to compile Lame 3.80 beta using MSVC 6.0 on Windows NT, with the included makefile.msvc. Two things : 1. brhist.c includes "termcap.h", which does not exist on the platform. Removing the include fixes it. 2.At link time, I get the following errors : main.obj : error LNK2001: unresolved external symbol _lame_close_infilemain.obj : error LNK2001: unresolved external symbol _lame_readframemain.obj : error LNK2001: unresolved external symbol _lame_init_infilemain.obj : error LNK2001: unresolved external symbol _lame_parse_argsmain.obj : error LNK2001: unresolved external symbol _lame_usage Grep reveals that get_audio.c contains (some of) these functions, and it _is_ being compiled. I have no idea what's going wrong... Oh well, at least compiling with Cygwin works fine. Martin Dufour
Re[2]: [MP3 ENCODER] Lame 3.80 Vrb q:
Hello Alberto, Monday, May 08, 2000, 5:37:55 PM, you wrote: AG By the way, LAME 3.80 puts a lot of "informative message" when AG encoding (the file is reservoir.c), and I find it a little annoying. AG Is this information useful? Is there any way to disable it? (apart from AG commenting the lines in the source code, that is) And it puts version number EVERY such frame. the latest cvs version does the same. i think this doesn't reduce size 8( LAME3.81 (alp__-¦Ã-ÐÀ+N â+P 8ha 1) Best regards, Dmitrymail to: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] free format bitstreams
The ISO spec says that free format bitstreams are limited to 320kbs, but lame will allow you to specify any bitrate over 8kbs. (lame prints warnings when using freeformat) According to my ISO doc (section 2.4.2.3), for layer III, decoders are not required to support higher free format higher than 320kbps. So free format is not restricted to =320kbps. And decoders must support free format at least up to 320k. Under windows, the results are the following: Winamp 2.6, new in-mpg123 for winamp, Nad 0.93, Sonique 1.51, AudioActive 1.93b, K-Jofol 0.6, Digideck 0.82, Winplay3 2.3, ActiveMovie/MediaPlayer 6.4, Xing MPEG player : all failed (quite disappointing) Regards, Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
faster mdct(Re: [MP3 ENCODER] Hardware reccomendation)
Segher Oh, by the way, anyone interested in better DCT's? Naoki I made faster mdct_long and sent it to Takehiro. and it was merged to my tree. maybe tomorrow, CVS tree will get it. it's very swift :) --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.80: Build problems w/NT
I tried to compile Lame 3.80 beta using MSVC 6.0 on Windows NT, with the included makefile.msvc. Two things : 1. brhist.c includes "termcap.h", which does not exist on the platform. Removing the include fixes it. 2. At link time, I get the following errors : main.obj : error LNK2001: unresolved external symbol _lame_close_infile main.obj : error LNK2001: unresolved external symbol _lame_readframe main.obj : error LNK2001: unresolved external symbol _lame_init_infile main.obj : error LNK2001: unresolved external symbol _lame_parse_args main.obj : error LNK2001: unresolved external symbol _lame_usage Grep reveals that get_audio.c contains (some of) these functions, and it _is_ being compiled. I have no idea what's going wrong... Oh well, at least compiling with Cygwin works fine. Martin Dufour Robert has just fixed this problems in CVS. Here's the new Makefile.MSVC: # Makefile.MSVC: MSVC Makefile for LAME 3.81 (alpha1) PGM = lame # Microsoft C options # CC = cl # LN = link # Intel 4.5 compiler CC = icl LN = xilink # debugging options # CC_OPTS = /nologo /Zi /Ge /GZ # LN_OPTS = /nologo /debug:full /debugtype:cv /fixed:no # profiling options # CC_OPTS = /nologo /Zi /O2ab2gitwy /G6AFs /DNDEBUG # LN_OPTS = /nologo /debug:full /debugtype:cv /fixed:no /profile # release options # CC_OPTS = /nologo /O2ab2gitwy /G6AFs /DNDEBUG # LN_OPTS = /nologo # Intel 4.5 options CC_OPTS = /nologo /DNDEBUG /Qunroll /O2 /G5AFs /QaxM /Qipo_obj /QIfist- LN_OPTS = /nologo GTK = GTKLIBS = SNDLIB = /DLAMESNDFILE LIBSNDFILE = LIBS = MAKEDEP = TIMER_SWITCH = BRHIST_SWITCH = # /DBRHIST LIBTERMCAP = CPP_OPTS = /DHAVEMPGLIB /DLAMEPARSE CC_SWITCHES = $(CC_OPTS) $(DISTRIB) $(SNDLIB) $(GTK) \ /DBS_FORMAT=BINARY $(TIMER_SWITCH) $(BRHIST_SWITCH) LN_SWITCHES = $(LN_OPTS) c_sources = \ main.c \ gtkanal.c \ gpkplotting.c \ brhist.c \ bitstream.c \ fft.c \ get_audio.c \ id3tag.c \ ieeefloat.c \ lame.c \ newmdct.c \ parse.c \ portableio.c \ psymodel.c \ quantize.c \ quantize-pvt.c \ vbrquantize.c \ reservoir.c \ tables.c \ takehiro.c \ timestatus.c \ util.c \ VbrTag.c \ version.c \ mpglib/common.c \ mpglib/dct64_i386.c \ mpglib/decode_i386.c \ mpglib/layer3.c \ mpglib/tabinit.c \ mpglib/interface.c \ mpglib/main.c OBJ = $(c_sources:.c=.obj) .c.obj: @$(CC) $(CC_SWITCHES) $(CPP_OPTS) /c $ /Fo$@ $(PGM).exe: $(OBJ) Makefile.MSVC @echo $(PGM).exe @$(LN) $(LN_SWITCHES) $(OBJ) $(LIBS) $(LIBSNDFILE) $(GTKLIBS) \ $(LIBTERMCAP) /out:$(PGM).exe /map:$(PGM).map clean: @-del *.obj @-del dll\*.obj @-del mpglib\*.obj rebuild: clean $(PGM).exe -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Hardware reccomendation
What is the encoding process bounded by? I/O operations or computational speed? computational speed On an embedded system with a K6-200 (without L2 cache!) and gogo 2.31 there was still CPU power left for other things. ...which means you are *not* cpu bound. My comment was related to *exact* realtime encoding. When doing so, the CPU load was around 35 % (-nopsy). Or 90 % with psychoacoustic model. (gogo 235) Frank -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Lame 3.80 Vrb q:
Hello Mark, Monday, May 08, 2000, 9:37:38 PM, you wrote: MT So lame3.81, which ignroes the 7680 bit buffer limitation will MT be out in a few hours. If you dont like the "informative message" MT try it out. mmm... but lame3.81 was already released... Best regards, Dmitrymail to: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame 3.80 Vrb q:
Hello Mark, Monday, May 08, 2000, 9:37:38 PM, you wrote: MT So lame3.81, which ignroes the 7680 bit buffer limitation will MT be out in a few hours. If you dont like the "informative message" MT try it out. mmm... but lame3.81 was already released... Best regards, Dmitrymail to: [EMAIL PROTECTED] That should have only been available from CVS. The latest strategy which I try to follow is: lame3.81 beta released lame3.82 alpha this code is what you get from CVS right now which is continuously changing. (Dmitry's versions have a date stamp?) lame3.82 beta the next release, whatever that may be. So as soon as 3.81beta was released, the CVS repository was updated to 3.82alpha. This system just kind of evolved this way and is somewhat error prone since it is a lot of things to update by hand. If someone has a better idea let me know. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame 3.80 Vrb q:
On Mon, 8 May 2000, Mark Taylor wrote: [snip] From discussions here, I think it is safe to remove this restriction but make an option to turn it back on. I liked the one suggestion of something hard to type like: "--strictly-enforce-ISO" :-) [snip] How about --iso-me-harder ? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame 3.80 Vrb q:
Mark Taylor schrieb am Mon, 08 Mai 2000: From discussions here, I think it is safe to remove this restriction but make an option to turn it back on. I liked the one suggestion of something hard to type like: "--strictly-enforce-ISO" :-) I tested a couple of players and they didn't have any trouble, but of course the best way is to put out a new *beta* release and see if anyone else has trouble. So lame3.81, which ignroes the 7680 bit buffer limitation will be out in a few hours. If you dont like the "informative message" try it out. Mark OK, all mpg123 based players have trouble with such encoded files: lame -b320 -h -mj t.wav t.mp3 resulting in lots of drop outs while playing back. But not only mpg123 based ones like xmms have trouble, freeamp doesn't like them too. Maybe we have to force using stereo on 320kbits streams, but there is a possibility that there are testcases where stereo ones will not work either. How about hardware players? Has someone tested one? Playing MPEG stream from t.mp3 ... MPEG 1.0, Layer: III, Freq: 44100, mode: Joint-Stereo, modext: 2, BPF : 1045 Channels: 2, copyright: No, original: Yes, CRC: No, emphasis: 0. Bitrate: 320 Kbits/s, Extension value: 0 Audio: 1:1 conversion, rate: 44100, encoding: signed 16 bit, channels: 2 Frame# 563 [ 2459], Time: 00:14.70 [01:04.23], mpg123: Can't rewind stream by 4096 bits! Frame# 603 [ 2419], Time: 00:15.75 [01:03.19], mpg123: Can't rewind stream by 4096 bits! Frame# 683 [ 2339], Time: 00:17.84 [01:01.10], mpg123: Can't rewind stream by 4096 bits! Frame# 711 [ 2311], Time: 00:18.57 [01:00.36], mpg123: Can't rewind stream by 4089 bits! Frame# 765 [ 2257], Time: 00:19.98 [00:58.95], mpg123: Can't rewind stream by 4096 bits! Frame# 806 [ 2216], Time: 00:21.05 [00:57.88], mpg123: Can't rewind stream by 4079 bits! Frame# 819 [ 2203], Time: 00:21.39 [00:57.54], mpg123: Can't rewind stream by 4096 bits! Frame# 926 [ 2096], Time: 00:24.18 [00:54.75], mpg123: Can't rewind stream by 4063 bits! Frame# 981 [ 2041], Time: 00:25.62 [00:53.31], mpg123: Can't rewind stream by 4090 bits! ... Robert -- e-mail: [EMAIL PROTECTED] homepage: http://linux.unixcity.de/catwalk/index.html -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] GA/GP
Mark Stier wrote: -BEGIN PGP SIGNED MESSAGE- Hello, have you ever thought of setting up a distributed Genetic Programming network which lets you optimize or even find algorithms suitable for music/speech compression 'automatically'? Maybe one could find algorithms that are even better than Frainhofer's. Regards, Mark ??? please elaborate -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Mp3 encoders quality tests
What do You recommend to me? Use the in_mp3.dll of v2.22? I stand to use Winamp because is the most extended Mp3 player. But I accept ideas. George - Original Message - From: "David Balazic" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, May 08, 2000 9:55 AM Subject: Re: [MP3 ENCODER] Mp3 encoders quality tests On the site you recommend WinAMP for the listening, while just recently a winamp bug was discussed on this list, which add corruptions during playback of mp3s ! The bug is present in winamp 2.62 ( latest as of this writing ), as reported on this list. david balazic George wrote: Hi to everyone! Just to say We've started the Mp3 Quality Tests. To continue the project We need volunteers to make auditions of Wav Mp3 files. If you're interested or know someone can be interested in, please go to http://www.hispamp3.com/bench/inde.htm or http://benchs.emp3.com . Everyone is welcomed. Thanks to all George "Mp3 Encoders Quality + Speed Stats" http://benchs.emp3.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame 3.80 Vrb q:
OK, all mpg123 based players have trouble with such encoded files: lame -b320 -h -mj t.wav t.mp3 resulting in lots of drop outs while playing back. But not only mpg123 based ones like xmms have trouble, freeamp doesn't like them too. Maybe we have to force using stereo on 320kbits streams, but there is a possibility that there are testcases where stereo ones will not work either. I was able to reproduce this, and it looks like it is not ISO buffer related (thankfully!). The side channel reduction algorithm which moves bits from the side channel to the mid channel, was letting the mid channel exceed 4095. (which is a limit that must be enforced!). Robert, for a quick check, compile with out -UNDEBUG and you should get a cod_info-part2_3_length 4095 assert() failure when encoding. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] -F not working in LAME 3.80
Hi, I found '-F' switch not working in LAME 3.80. It's just a silly bug: in line 628 of parse.c the '=1' assingment is missing. By the way, I've just found a little sample where, after enconding, there's a 48 kbps frame, and I used the '-b 96' setting (without '-F'). Is that normal? The sample is about 50 KB, if any interested in it. The previous frame is 32 kbps and the next is 256 kbps. email:[EMAIL PROTECTED] -= Alberto García =- http://www.cryogen.com/berto Clave pública PGP disponible Fidonet: 2:348/105.108 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
