Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Gargos Chode wrote about the -k switch: Hrmm... that is an interesting idea. I completely hadn't thought of this. Does this actually take away bits from being used to encode the audio frame? If so then what is the real use of this switch? I had thought this switch would help to prevent the mp3 from being possibly corrupted by being transferred over and over again. Not that this really happens often but I thought why not. If however this switch really isn't that useful and it takes bits away from being used to encode the audio then I will stop using it. Currently I haven't noticed any degredation in sound just through normal listening tests, although I haven't looked into the matter further. I will do some testing and see if encoding without this switch seems to have any impact. It takes something around 612 bits/s. This is less 0.5% for 128 kbps, even less for higher bit rates. It becomes interesting for bitrates in the range from 8...24 kbps. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] VBR brutal test file, bug in ATH?
I've started testing Lame with synthetic input to test some lame properties. One is a dual tone sweep, a slow araising sweep from 16 Hz to 14 kHz and a second arising from this frequency up to 18 kHz. CBR (-b160): adds some clicks at the end of every fast sweep VBR (-V4): sounds really worse. All kinds of errors on a very high level. May be also coding errors (it sounds like a lot of bit errors AND masking errors). VBR (-V0): sounds equal to CBR VBR (-V4 --noath): sounds equal to CBR VBR (-V4 -b112) sounds equal to CBR VBR (--athlower 80): sounds equal to CBR So I expected it is a ATH problem. But reducing input by 24 dB don't enforce or reduce the problem. Tests on -48 dB are not possible because of the limited input precission, quantization noise becomes important and makes listening tests inpossible. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] AIFC - MP3 encoding
Chad Cunningham wrote: Hi, I seem to have hit a wall here... I want to do an mp3 ripper for Mac OSX, which I thought would be a simple enough project, but it's getting more complicated. The OS automatically mounts cd's in a /Audio CD directory as aiff files. I thought this would make things easy as I could just write a front end which needed no CD access and could just work with the files. However, it turns out that they are actually AIFC files. This has caused me some problems as lame, sox, and anything else I can find cannot deal with AIFC. So I went back to the drawing board and planned to just access the cdrom and rip the tracks off, however I've learned that for some reason, OSX set's the cd device to root read only. Now this makes absolutely no sense to me, but at least they do state that this "may change" in the future. So the up shot is, if I want this to be available as an end user product, I can't access the cdrom directly at this time. You can make your program setuid root :-) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MP3 encoding speed : LAME XING
On Fri, 6 Oct 2000, engdev wrote: You're right Mark, compared to Lame 387 MMX --abr 128 Xing is only two times faster Bo) Regards, Wim Speekenbrink Using 160kbps for both LAME and Xing, encoding "Dire straits - telegraph road" LAME takes about 1.5 times longer than Xing. Is that the MMX version of LAME? Mark Powell - UNIX System Administrator - The University of Salford Academic Information Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Hello, Hrmm... that is an interesting idea. I completely hadn't thought of this. Does this actually take away bits from being used to encode the audio frame? If so then what is the real use of this switch? I had thought this switch would help to prevent the mp3 from being possibly corrupted by being transferred over and over again. Not that this really happens often but I thought why not. If however this switch really isn't that useful and it takes bits away from being used to encode the audio then I will stop using it. Currently I haven't noticed any degredation in sound just through normal listening tests, although I haven't looked into the matter further. I will do some testing and see if encoding without this switch seems to have any impact. -p is for adding a crc check to every frame. It does not prevents any corruption of the bitstream, it just help to detect if it has been corrupted. As it uses bits for the crc, it will lower (a little) the quality of CBR encoding, and will higher the filesize of vbr. 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/ )
Re[6]: [MP3 ENCODER] -q1
Hello Gargos, Friday, October 06, 2000, 2:13:24 AM, you wrote: GC Hello, GC Roel, maybe you should give these settings a try on that track: GC -V1 -mj -b128 -q2 -d -k --nspsytune --athlower -35 -X3 GC The bitrate stays pretty low (~224kbps) and it sounds very good... GC almost identical to the original. These are the only settings I GC could find that produce a smaller file than using 256kbps that GC still sounds good (actually it sorta sounds a bit better.. seems GC the noise is less harsh than that generated by 256kbps). It sounds much better on fatboy than the other options. GC I'd like to hear your thoughts on these settings. I think it's possibly only usable on this fatboy example. On velvet it sounds really poor and the bitrate is much too high: 32 [%.9]* 128 [ 4%]* 160 [ 8%]* 192 [13%]** 224 [14%] 256 [15%]* 320 [46%]** average: 257.9 kbps also: isn't that "-35" not extremely harsh on the athlower? -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] modularization
Hi, I browsed the archive and have some comments: Takehiro wrote: (install prefix) BTW, default is changed /usr/include, by Florian. I think we should use /usr/local. At first I used /usr/local, but it seems that /usr/local/lib isn't in the standard library path. It seems that not many programs use /usr/local as prefix at all (though it should be /usr/local - but what use are conventions if they aren't followed by standard Linux distributions ?). Mark wrote: There are some issues related to this if the library becomes a popular shared library. However, there is only 1 application which uses LAME as a shared library, and it uses a built in feature of Linux to check the version number before running. So right now the shared library issues are moot. It is more important to get the static library working than it is to solve all issues related to the shared library. Version checking is automatic for all UNIX based shared libs (that I have seen). It could be added a lame API function like get_lib_version(int* major, int* minor) which lets shared lib users decide whether the lib is fitting: minor version changes are upward compatible, major version changes are incompatible. This function is targeted for developers using the shared lib on systems without versioning support like Windows. Florian -- Florian Bomers - [EMAIL PROTECTED] http://www.bome.com : My personal homepage with Freeware and Shareware programs for musicians and developers. http://tritonus.org : Open source implementation of the Java Sound API, especially for Linux. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[6]: [MP3 ENCODER] -q1
also: isn't that "-35" not extremely harsh on the athlower? I think that using a negative value with athlower is a bad idea. 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/ )
Re: Re[6]: [MP3 ENCODER] -q1
-- On Fri, 6 Oct 2000 16:40:23 Roel VdB wrote: It sounds much better on fatboy than the other options. GC I'd like to hear your thoughts on these settings. I think it's possibly only usable on this fatboy example. On velvet it sounds really poor and the bitrate is much too high: Im not sure which part exactly you mean sounds very poor. The only thing that I could hear in the encoded mp3 is that perhaps a around 3 of the cymbal hits throughout the clip sound a bit louder on the right channel. This particular sound does not seem to appear on the file encoded with your settings. However when the different waveforms of the mp3s are subtracted from the original in cool edit, the normal settings show much more noise than the settings I suggested. This seems to be the case with every mp3 I have encoded to compare to two, so I am not quite sure why it is that in velvet.wav I would be hearing these sounds.. perhaps it is a bug? If it is simply noise that is causing the sound then how could that be possible when the peaks of the errors in the waveforms are also much lower in these settings than the ones you use? For clarity I have made screenshots showing the result of the waveform subtraction on the two different mp3s (using the same technique that you ha! ve used on your page to compare noise levels between encoders): http://www.geocities.com/gaordgvwyse/normal.jpg are the normal settings and http://www.geocities.com/gaordgvwyse/normal.zip is that waveform saved and zipped. http://www.geocities.com/gaordgvwyse/alternate.jpg are the settings I suggested http://www.geocities.com/gaordgvwyse/alternate.zip and the zip of that waveform. 32 [%.9]* 128 [ 4%]* 160 [ 8%]* 192 [13%]** 224 [14%] 256 [15%]* 320 [46%]** average: 257.9 kbps Im curious, what version of lame are you using, and did you compile it yourself? I ask because the bitrate I get from encoding with these settings is different than what you posted. Here are my results: LAME version 3.87 (beta 1, Sep 29 2000)(http://www.mp3dev.org) Win32 binaries from www.chat.ru/~dkutsanov/ polyphase lowpass filter disabled Encoding velvet.wav to velvet.wav.mp3 Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=2 Frame | CPU time/estim | REAL time/estim | play/CPU |ETA 455/455 (100%)|0:05/0:05|0:06/0:06| 2.1595x|0:00 32 [%.9]* 128 [ 4%]* 160 [ 8%]* 192 [12%]* 224 [13%]* 256 [14%]*** 320 [48%]** average: 260.4 kbps also: isn't that "-35" not extremely harsh on the athlower? I'm not quite sure I understand what you mean by this. Anyway, I would like to get to the bottom of this issue, perhaps someone can shed some light on this? Dibrom 10% cash back on all your calls through 2000 at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[8]: [MP3 ENCODER] -q1
Hello Gargos, Saturday, October 07, 2000, 1:40:57 AM, you wrote: GC Im not sure which part exactly you mean sounds very poor. The graphs you provided show a lower noise, this because --nspsytune probably. It simply sounds poor, really poor. It sounds nothing like the original on my headphones. Why go for this 260kbit/s average file when a 256S sounds just fine? I'm convinced the big problem is the JS here, but nonetheless it sounds poor and -V1 -q1 sounds much better on velvet in quite obvious manner. GC Im curious, what version of lame are you using, and did you GC compile it yourself? I ask because the bitrate I get from GC encoding with these settings is different than what you posted. GC Here are my results: I use the one with the "RH extensions" from Dmitry. (thanks for all the compiles and hard work Dmitry btw!) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[8]: [MP3 ENCODER] -q1
Hello, I use the one with the "RH extensions" from Dmitry. (thanks for all the compiles and hard work Dmitry btw!) Do you have a link to this version? I would like to try it out. Thanks. Dibrom 10% cash back on all your calls through 2000 at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
