Re: [MP3 ENCODER] MP3 encoding speed : LAME XING
The Xing MP3 encoder is exceptionally fast. Do they cut corners to get such high performance? Is their code written in assember? Who knows how did they program it... But they did sacrifice some quality. What (if any) chance of getting similar speed out of LAME? LAME is pretty fast too. I haven't benchmarked and compared both, though. Would you please do it and post the results? :-) The Xing encoder is quite limited with regard to input sampling frequencies and output bitrates. Has anyone done testing on quality? LAME definitely delivers higher quality than Xing. Xing isn't the worst encoder, but isn't the best either. Owen - Zia -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
I think Roberts code should be included and implemented with a switch so us "non-compilers" can test it. Ross. Roel VdB wrote: Hello Robert, Thursday, September 28, 2000, 8:12:59 PM, you wrote: RH Dmitry schrieb am Don, 28 Sep 2000: but what version i have to upload??? from project file or from makefile??? with 'Robert's alternate code' enable or disable??? RH Well, officially the one with 'Robert's alternate code' RH commented out. Sorry for the confusion. Robert, please consider defaulting the enhancements. It improves the 'velvet' track quality considerable in JS mode. Is there a downside to this 'alternate code'? -- Best regards, Roel mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
Ross Levis schrieb am Fre, 29 Sep 2000: I think Roberts code should be included and implemented with a switch so us "non-compilers" can test it. look at Dmitry's site, there it is for Windows users. http://www.chat.ru/~dkutsanov/~index.htm The latest alpha versions from CVS Repository. For testing purposes only!!! lame387nic with MMX support and Robert's alternate code lame-2928n with Robert's alternate code Ross. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] id3v2 xing-header
Hallo, I'm new to the list, and think bug reports are best posted here. I just downloaded version 3.87 beta, and tried the vbr. But it seems to have problems when writing ID3v2-Tag and the Xing VBR header together. Then the Xing-header is corrupt, or not found (The first frame doesn't contain the String "Xing"). If you don't write the id3v2-tag, the xing-header is OK. I took a look at the sources, but I cannot find the bug. I have problems with my tools displaying the correct info about the vbr-files, although I implemented the Xing-header recognition. (My program is MP3-Info Extension (for Windows explorer), and can be found on http://www.mutschler.de/mp3ext, with sources) -- Best regards, Michael Mutschlermailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
hi -- This is my first post to the list. I've been helping myself to the cvs source code for a few months now and this is a subject I have done some experimentation with. the only drawback I've found when using --nspsytune in vbr mode is that the average bitrate may increase somewhat dramatically. In one of my test cases (10 second clip) the avegare bitrate is 290 with --nspsytune vs 210 without it. lame version is 3.87 beta 1, options used were -b 128 -h -m j -q 1 -V 1 [--nspsytune] anyone interested in the clip can mail me. I have a small collection of 10 second clips that produce similar results. I also have samples which produce smaller average bitrates with --nspsytune. from now on I usually take some 30 seconds of source material and encode it both with and without --nspsytune to determine which will produce the smallest average bitrate before encoding the whole project. in cbr mode I prefer to use --nspsytune at all times. for the same reason naoki shibata and others have mentioned. On Fri, Sep 29, 2000 at 01:09:16PM +0900, Naoki Shibata wrote: I've asked some people to evaluate --nspsytune, and most of their response were positive ones. In VBR mode, --nspsytune usually improves sound quality with high tonality like piano and tambourin but sometimes degrades sound with low tonality like snare drums. In CBR mode, --nspsytune lowers artifacts in high frequency. -- Michael Horan III PGP signature
Re: [MP3 ENCODER] Intel Compiler
Joshua Bahnsen schrieb am Fre, 29 Sep 2000: There is only a problem with the Intel compiler if you compile on Win 95/98. If you actually use Win NT/2000 as your OS, binaries compiled with the Intel compiler run just fine on NT/2000 and ME/95/98. If you want an example, I've posted binaries of both VC5 and IC on http://www.geocities.com/archie69bj, I noticed that they run 10-15% faster on 2000 than with ME, it's nice. I also screwed around and added a version tab... Anyway, if you use Win2K and want a faster binary, here is one... Josh My experiences with the Intel compiler are, that you can tune it to produce faster code, but I had often a version that screwed down the quality. If you found some interesting working compile switches, maybe you will share them with us? By the way, the switches in Makefile.MSVC are tuned for my Pentium MMX. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --nspsytune
Yog Sothoth schrieb am Fre, 29 Sep 2000: hi -- This is my first post to the list. I've been helping myself to the cvs source code for a few months now and this is a subject I have done some experimentation with. the only drawback I've found when using --nspsytune in vbr mode is that the average bitrate may increase somewhat dramatically. In one of my test cases (10 second clip) the avegare bitrate is 290 with --nspsytune vs 210 without it. lame version is 3.87 beta 1, options used were -b 128 -h -m j -q 1 -V 1 [--nspsytune] anyone interested in the clip can mail me. I have a small collection of 10 second clips that produce similar results. I also have samples which produce smaller average bitrates with --nspsytune. from now on I usually take some 30 seconds of source material and encode it both with and without --nspsytune to determine which will produce the smallest average bitrate before encoding the whole project. This is a not so good idea. Take for example vbrtest.wav from LAME's homepage. Encode it with and without --nspsytune. Following your logic you would not using --nspsytune, but it was specially tuned to make this one good sounding, needing more bits. If you want some example where --nspsytune hurts, you can get spahm.wav there too. in cbr mode I prefer to use --nspsytune at all times. for the same reason naoki shibata and others have mentioned. On Fri, Sep 29, 2000 at 01:09:16PM +0900, Naoki Shibata wrote: I've asked some people to evaluate --nspsytune, and most of their response were positive ones. In VBR mode, --nspsytune usually improves sound quality with high tonality like piano and tambourin but sometimes degrades sound with low tonality like snare drums. In CBR mode, --nspsytune lowers artifacts in high frequency. -- Michael Horan III Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Intel Compiler
Basically, all I did was use the default switches in the VC workspace and added /QaxiM (so in the MSVC makefile, there was only difference, I never even looked at it though), I wasn't sure what else to add, I went to Intel's web page and looked at a list of all of the switches, but wasn't sure what else to use. I tested both versions (VC and IC) with 7 or 8 different mp3s, all produced the same output, byte-for-byte, but those are just the files I tested (Goldie Adam F, drum bass). Maybe there are cases where the IC will screw it up, but so far I never noticed a difference. Josh - Original Message - From: "Robert Hegemann" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 29, 2000 10:00 AM Subject: Re: [MP3 ENCODER] Intel Compiler Joshua Bahnsen schrieb am Fre, 29 Sep 2000: There is only a problem with the Intel compiler if you compile on Win 95/98. If you actually use Win NT/2000 as your OS, binaries compiled with the Intel compiler run just fine on NT/2000 and ME/95/98. If you want an example, I've posted binaries of both VC5 and IC on http://www.geocities.com/archie69bj, I noticed that they run 10-15% faster on 2000 than with ME, it's nice. I also screwed around and added a version tab... Anyway, if you use Win2K and want a faster binary, here is one... Josh My experiences with the Intel compiler are, that you can tune it to produce faster code, but I had often a version that screwed down the quality. If you found some interesting working compile switches, maybe you will share them with us? By the way, the switches in Makefile.MSVC are tuned for my Pentium MMX. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] -q1
Hi all, does someone know any sample where a VBR encoded MP3 with -q1 gives a better sounding MP3 compared to a same sized VBR with -q2 ? Ciao Robert PS: for VBR -q2 equals -h and is the default if you leave out -qx, -h or -f -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MMX question
Oh, oh no!
Do you want to start a contest of writing the dirties possible program?
main(_){float x,sin();for(_=0;__*_8;_+=_) ...
you forget the reverse access to arrays :-)
int a[5];3[a]=2;
--
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] MP3 encoding speed : LAME XING
The Xing MP3 encoder is exceptionally fast. Do they cut corners to get such high performance? Is their code written in assember? What (if any) chance of getting similar speed out of LAME? The Xing encoder is quite limited with regard to input sampling frequencies and output bitrates. Has anyone done testing on quality? The Xing encoder is not a reference in term of quality. It's right that it's fast, but now the new FhG engine is as fast as xing, but with a better quality. Yes, Xing cuts corners. An example is that it only uses long blocks, and thus doesn't compute short ones. Yes, it contains a lot of assembler and mmx code. And yes, there is a chance to get similar speed but with a lot higher quality with lame, one day. The priority with Lame is quality, so quality improvments are made first. Before optimizing to mmx a function, we must be sure that this function won't be upgraded soon, this is why there is only a few mmx on Lame. 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/ )
[MP3 ENCODER] Re: LAME 3.87 on freshmeat.net
That was written about a year ago by the authors not me.. I just notice the new versions report them.. Submit the change to freshmeat or tell the lame guys to do it. peace, jolan On Sat, 30 Sep 2000, Takehiro Tominaga wrote: Hello, jolan, from one of LAME developper. On the freshmeat.net, you introduced LAME 3.87beta is patch for ISO demonstration source and depends on ISO dist10. and License is GPL. that's completely wrong :) LAME is now LGPL/GPL dual licensing. and LAME3.80 and later is NOT patch, but whole source. Regards, --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Intel Compiler
NT users, please, test this compile: http://www.chat.ru/~dkutsanov/lame387mmx.zip Best regards, Dmitrymail to: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Intel Compiler
Dmitry wrote: NT users, please, test this compile: http://www.chat.ru/~dkutsanov/lame387mmx.zip I can't get any of the Intel compiled exe's to run on my old pentium pro 200 under Win2k. Both of the 3.88a1's from Joshua crash and so does the new MMX from Dmitry - as an external compressor to EAC. The only one that works is the 'lame387' - 3.87beta (9/26) release. Is it looking for MMX on my processor and then crashing, or is there something different in the 3.88 code that would do it? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Intel Compiler
Hello John, Saturday, September 30, 2000, 2:38:44 AM, you wrote: JS Dmitry wrote: NT users, please, test this compile: http://www.chat.ru/~dkutsanov/lame387mmx.zip JS I can't get any of the Intel compiled exe's to run on my old pentium pro JS 200 under Win2k. Both of the 3.88a1's from Joshua crash and so does the JS new MMX from Dmitry - as an external compressor to EAC. try this http://www.chat.ru/~dkutsanov/lame387.zip Best regards, Dmitrymail to: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] modularization
I just separated frontend from library. but many things does not work correctly yet (VBR histgram, etc), or even checked(many configure option, etc). Mark suggested that "library" code should be in the libmp3lame, but before moving to it, I want to everyone to check my modifications. We are at the start point of the modularized work. This is not the final release. Probably there are too many bugs. Probably you can't agree with my modularization policy. So, tell me your opinion and bug reports. It passes all my test cases, so no unexpected changes to the algorithms :-). I had some comments yesterday, but I see a lot of them have already been fixed today. some thoughts: VbrTags: The library needs functions to create VBR tags, and get_audio.c needs functions to read VBR tags. So we can either add VBR tag code to the front end (duplicating code that is in the library), or we can expose some kind of VBR tag code in the library interface. Creating VBR tags has the problem that it needs to rewind the file and write at the beginning. This is the only place now where libmp3lame does any file I/O. But at least it does not open or close the file. id3tags: looks like you've fixed this already? Although now there is a lame-id3tag.h header file in addition to lame.h. I would be tempted to merge this into just lame.h. Also, for installation, I think 'lame' should be statically linked for now. And should lame-analysis.h really be installed by default in /usr/local/include directory? I was thinking we should make a 'mp3x' directory, and put all the mp3 frame analysis code in there (and remove the 'lame -g' option) The frame analyzer is not of general interest - it is just a tool for developers. I will some time tomorrow to look around some more. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
