Re: [MP3 ENCODER] Interesting high quality settings and possible bug
pretty much the best I could get but I know for example that --nspsytune normally enables -X1, but -X3 sounds quite a bit better although it is significantly slower... which isn't too big of a deal to me. Also, I know that from earlier conversations --athlower isn't perhaps the greatest way to control file size (which is what I am using it for)... however without it the files average 270kbps or more usually which is a bit too big... using --athlower they come down to around 230kbps average, although I have had files which reached all the way up to 290kbps. It also seems that these particular settings allow a larger bitrate range (ive seen from ~150 to ~290kbps), while the older settings seemed limited to around ~170 to ~230kbps.. I plan on posting some information about all of the tests and stuff that I have done on a website soon.. I would like to hear some opinions on these settings and my findings. Oh... and about that possible bug... when using these settings, ocassion! At these types of average bitrates, I think you might be better off with CBR instead of VBR. This is because with an average bitrate 230kbs, you only need an extra 90kbs to go up to 320kbs. 90kbs is only 40% of the average frame size - these types of fluctuations are easily handled by the bitreservoir in CBR mode. (it can handle such a fluctuation in 25% of the frames) VBR is more usefull at lower bitrates: take an average bitrate of 128kbs, where you need an extra 250% of the average frame size to make it up to 320kbs. CBR mode can handle such a fluctuation, but for only about 4% of the frames. aly (about 1 in 10 times or a bit less) while encoding lame will start giving an error saying: ERROR: MAX_HEADER_BUF too small in bitstream.c The last time I saw this error, it turned out to be because the user was overclocking his system and it was unstable. If that is not the problem, then you need a version of LAME compiled with debugging information turned on. LAME will then probably stop before MAX_HEADER_BUF overflows, with a different, more informative message. Did you compile lame yourself? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Parameter setting functions...
I am planning XML like interface of LAME parameter handling. I will mail or commit the base code. It will be completely easy and feature extendable. --- [EMAIL PROTECTED] // may the source be with you! Both methods (thousands of functions and thousands of tags) are equivalent: * use one function ( lame_ioctl() ) and thousands of constants to tell this function what functionality is actually requested * use thousands of functions (lame_x () ) to execute a functionality The difference is that second possiblity is more type safe, and the first really looks like you never need to change the API, which is only partially true (backward linking is possible, but you have still a runtime error, this is often called error obscuring). -- Frank "C programmers hate readable programs" Klemm M I am afraid I actually agree with Frank on this point :-) M With the tags, you need to add a line in lame.h for each M variable, as well as 3 lines of code in a big 'switch' M statement in lame.c -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
At these types of average bitrates, I think you might be better off with CBR instead of VBR. This is because with an average bitrate 230kbs, you only need an extra 90kbs to go up to 320kbs. 90kbs is only 40% of the average frame size - these types of fluctuations are easily handled by the bitreservoir in CBR mode. (it can handle such a fluctuation in 25% of the frames) VBR is more usefull at lower bitrates: take an average bitrate of 128kbs, where you need an extra 250% of the average frame size to make it up to 320kbs. CBR mode can handle such a fluctuation, but for only about 4% of the frames. Well I actually have thought of using just straight CBR but in most of the cases that I have tested these particular VBR settings seem to perform better. For example, when encoding fatboy.wav with these vbr settings the file size is around 224kbps or something, i dont recall exactly now when I encode fatboy.wav with lame -b256 -mj -q2 --nspsytune -X3 (and also without --nspsytune) the CBR file clearly has more noise in the background than VBR file... for me to get a CBR that sounds as good I have to bump up the bitrate to 256kbps. Granted, 224 to 256 isnt that big of a difference, but if it sounds better at a lower bitrate then why not use it? Earlier I remember there being some talk about --nspsytune spending too many bits on tonal parts of audio clips... i think that if this hasnt been resolved, that when it is, it should probably result in even smaller files with possibly the same level of quality. I have noticed that on most of my music, the more melodic stuff is us! ually what ends up being encoded at bitrates of 250kbps and above. If the effeciency of --nspsytune in those cases can be improved them filesize should become less of an issue, and will make these particular VBR settings more appealing. The last time I saw this error, it turned out to be because the user was overclocking his system and it was unstable. If that is not the problem, then you need a version of LAME compiled with debugging information turned on. LAME will then probably stop before MAX_HEADER_BUF overflows, with a different, more informative message. Did you compile lame yourself? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) I am 100% sure this is not the case. Although I will admit that my system is overclocked I have run extremely extensive tests (prime95 for days, etc) and I usually have uptimes of several weeks, while running graphics programs, games, running an ftp server, encoding mp3s, etc. Lame is the only thing affected, and only when using these settings. As for the version I am using, it is here: http://www.chat.ru/~dkutsanov/lame387mmx.zip It seems to work great other than that particular error every once in awhile... usually if I go back and reencode the song it will work ok, although there was one particular song (I'll try to find which one it was) where it took 5 tried before it would fully encode. Thats about it... although I am kinda hoping to get some more comments on the particular settings themselves... One thing I am kinda wondering about is how the whole -X switch fits into the equation... I have tried every -X switch with those settings and -X2 and -X3 are the only ones which seemed to encode various test files without errors... is there something special about how those relate to the other settings? Also, the reason I use --nspsytune is because it usually seems to further reduce filesize (at least in the case of fatboy.wav... the bitrate drops from around 270 to 220kbps)... can anyone explain how or why this happens? Is it a bad idea to use it in most situations? I have tried using -q1 in combina! tion with --nspsytune because of earlier discussions saying they could be complimentary, but it seems to either have no effect (most of the time) except being significantly slower, or it actually makes the file sound worse. I am wondering again if -X3 maybe has something to do with that. Any ideas? Dibrom Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME file name changes from 3.86 to 3.87?
:: :: :: That name was changed because one make system (MSDOS?) interpreted :: the '-' in quantize-pvt.c as a compiler option. :: MSDOS can't store a name like "quantize-pvt.c", you got at most: "quantize.c" or "quanti~1.c". -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] -q1
On Thu, 5 Oct 2000, Robert Hegemann wrote: From your recent postings I'm detecting that you think -q1 can only rarely give a sonic improvement. In fact it is more likely to degrade the sound over -q2? If so, the Roel recommendation of -q1, seems a little dangerous? You think the extra ~5% file size, that encoding using -q2 requires, usually provides superior sound quality? I don't know any track where the use of -q1 improves sound quality compared to a same sized -q2. That's why I'm asking you all. To be honest I haven't spotted any difference. I don't have decent headphones and find listening tests on my HiFi arduous. I'll stick with -h if there's some doubt over the quality of -q1. I like the extra encode speed too :) I think Roel is the fella who swears by -q1. Maybe he's best to ask? Cheers. 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[2]: [MP3 ENCODER] -q1
Hello Robert, Thursday, October 05, 2000, 12:08:21 AM, you wrote: RH I don't know any track where the use of -q1 improves sound quality RH compared to a same sized -q2. That's why I'm asking you all. The reason I use it on -V1 is: I don't get poorer quality (still waiting for my one sample) and I get fairly decent size benefits, what VBR is all about. On the velvet track, both -V1 -q1 and -V1 have a noise in the R channel in MJ mode. It's not extremely harsh, and with that new 'Robert's alternate code', which I hope will be default in 3.88, the amount of JS noise is even less. You could say: use -V2 instead of -V1 -q1, but I found the first sounding less good than the latter. About the 'same sized': how do you get the -q1 and -q2 to be of equal size? -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] -q1
-- On Thu, 5 Oct 2000 11:05:14 Roel VdB wrote: Hello Robert, Thursday, October 05, 2000, 12:08:21 AM, you wrote: RH I don't know any track where the use of -q1 improves sound quality RH compared to a same sized -q2. That's why I'm asking you all. The reason I use it on -V1 is: I don't get poorer quality (still waiting for my one sample) and I get fairly decent size benefits, what VBR is all about. On the velvet track, both -V1 -q1 and -V1 have a noise in the R channel in MJ mode. It's not extremely harsh, and with that new 'Robert's alternate code', which I hope will be default in 3.88, the amount of JS noise is even less. You could say: use -V2 instead of -V1 -q1, but I found the first sounding less good than the latter. About the 'same sized': how do you get the -q1 and -q2 to be of equal size? -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) Hello, Have you tried using -q1 on fatboy.wav? It sounds significantly worse than -h or -q2. If you dont have this file let me know and I will send it to you. Dibrom Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Ross Gargos Chode wrote: Ross Ross -V1 -mj -b128 -q2 -d -p -k -F --nspsytune --athlower -35 -X3. Ross Ross Some thoughts: Ross Ross -p -F will have no effect on sound quality. I have had mixed results with nspsytune. -X2 X3 both produce massively larger average bitrates than all the others. I've never played with -d. Can someone tell me if allowing channels to have different blocktypes has any bad side effects? ie. ISO or decoder compatibility? First, one should not specify "--athlower -35". This may significantly degrade sound quality. I always used -q1 while tuning --nspsytune. I think -q1 doesn't degrade sound quality so much with --nspsytune. Theoretically, -X doesn't affect sound quality in VBR mode. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
if lame writes a 16 bit crc for every frame (using -p switch), doesn't that mean there are 16 less bits for sound data for each frame? couldn't that affect sound quality? is this getting carried away a little too much? :) On Thu, Oct 05, 2000 at 09:30:23PM +1300, Ross Levis wrote: -p -F will have no effect on sound quality. I have had mixed results with nspsytune. Ross. -- Michael Horan III PGP signature
[MP3 ENCODER] bug in bitrate analysis with 3.88a
This is a forwarded message Date: Thursday, October 05, 2000, 11:23:08 AM Subject: Problems with Lame 3.88alphas + A question ===8==Original message text=== Hi, skip Also the lame 3.88alphas don't run propley on my machine. When I encode a file the screen keep rolling. This is reallt annoying. skip ===8===End of original message text=== Best regards, Dmitrymail to: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
RAW sizes differ between the original and the encoded-decoded files, headers appear to be same (44 bytes) size. - original wav - raw = header t4 14,276,68414,276,640 44 - encoded then decoded back (cbr and vbr) t4_b256_ms_h14,275,81614,275,772 44 t4_V1_b128_mj_q1_t 14,275,81614,275,772 44 The original .wav is reported to be 0:00.005 longer (1:20.933 vs. 1:20.928). The 1/200s difference might well account for the 868 extra bytes. Whether this is normal or accidental from the lame standpoint, I don't know. Liviu - Original Message - From: "Mark Taylor" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 02, 2000 10:15 PM Subject: Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip True, it was the -t encode switch. By the way, isn't "lame -?" -t disable writing wav header when using --decode a bit misleading about this? Yes, that is a little misleading: "-t" option is listed twice, since it disables wav headers when decoding, and disables Xing headers when encoding. Thank you, Liviu P.S. The resulting .wav's are slightly _smaller_ than the original, see file listing below - t4.wav is the original wav, t4*.mp3 the encoded mp3's and t4*.wav the decoded wav's. Could easily be a bug in LAME. But before I look into this, can you do one more thing: compare the .wav headers? LAME writes a very spartin .wav header. t4.wav may include some extra "chunks" not in the LAME produced wav headers. 14,276,684t4.wav 2,590,511t4_b256_ms_h.mp3 1,862,685t4_V1_b128_mj_q1.mp3 1,862,268t4_V1_b128_mj_q1_t.mp3 14,275,816t4_b256_ms_h.wav 14,280,424t4_V1_b128_mj_q1.wav 14,275,816t4_V1_b128_mj_q1_t.wav There does seem to be a bug in lame 3.87 - the decoder no longer recognizes the VBR header, and instead encodes it as silence. This is why t4_V1_b128_mj_q1.wav is larger. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] AIFC - MP3 encoding
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. So I'm back to square 1, how can I go from AIFC to MP3? I have no real experience with sound file formats and I really just want to write a front end which uses tools written by people who know a lot more than me such as lame :) Any tips are appreciated. -- Chad Cunningham [EMAIL PROTECTED] [+-].++[+++-].-.+.---. [--]---.+[++-]-.++[--].++.---.+ +++[---]--.++[-]-.+[-]-.[- -]-.+++..---.+.+++[]. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] -q1
Robert Hegemann schrieb: Mark Powell schrieb am Mon, 02 Okt 2000: On Fri, 29 Sep 2000, Robert Hegemann wrote: 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 ? From your recent postings I'm detecting that you think -q1 can only rarely give a sonic improvement. In fact it is more likely to degrade the sound over -q2? If so, the Roel recommendation of -q1, seems a little dangerous? You think the extra ~5% file size, that encoding using -q2 requires, usually provides superior sound quality? I don't know any track where the use of -q1 improves sound quality compared to a same sized -q2. That's why I'm asking you all. Ciao Robert Why not making q1 default for only V5V9 Bye Stephan -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
No Subject
Hello LAME Developers, I was just wondering if anyone has been to able build the GTK version of LAME 3.87. I have tried with the makefile for MSVC and by using the project files. I have gotten the same error in both cases: c:\lame-beta\src\lame3.87\main.c(154) : error C4013: 'lame_decoder' undefined; assuming extern returning int This only happens, when I use the HAVEGTK option. I have no idea how to go about fixing this. Perhaps I have missed something. Has anyone else be getting this error? Thanks for any help, Nathan D. Blomquist http://www.win32lame.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] AIFC - MP3 encoding
[...] So I'm back to square 1, how can I go from AIFC to MP3? I have no real experience with sound file formats and I really just want to write a front end which uses tools written by people who know a lot more than me such as lame :) Any tips are appreciated. There's one really simple solution to this, and that is to either compile in libsndfile ( http://www.zip.com.au/~erikd/libsndfile/ ) with LAME, or get a precompiled one (check out the links at the project page: http://www.mp3dev.org/mp3/ ) which uses libsndfile... - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] AIFC - MP3 encoding
Howdy, Unless they have changed it significantly since I last looked at it (quite a while ago) AIFC is just AIFF with the added possibility of using compressed audio instead of raw PCM. Either format is 'chunk' based, like RIFF-WAVE. That is, an AIFF/C file consists of a number of chunks, most of which are informational, and one of which is data. To unpack the audio, you would just have to parse the file, throwing away chunks until you hit the data chunk. I doubt that OSX is doing anything to the raw data itself other than wrapping it into the data chunk, so you should be golden from there. If you can't find it anywhere else, you can buy the AIFF/C specification from Apple; it's in one or more of the Inside Macintosh series of books. Alex PS - If you weren't planning to write any code, I'd suspect that you might be able to use ResEdit or something similar to simply change the type of the AIFC file to AIFF - but I can't guarantee that method. -Original Message- From: Chad Cunningham [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 05, 2000 3:33 PM To: [EMAIL PROTECTED] Subject: [MP3 ENCODER] AIFC - MP3 encoding 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. So I'm back to square 1, how can I go from AIFC to MP3? I have no real experience with sound file formats and I really just want to write a front end which uses tools written by people who know a lot more than me such as lame :) Any tips are appreciated. -- Chad Cunningham [EMAIL PROTECTED] [+-].++[+++-]. -.+.---. [--]---.+[++-]-.++[- -].++.---.+ +++[---]--.++[-]-.+[+ +++-]-.[- -]-.+++..---.+.+++[]. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- 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. Dibrom -- On Thu, 5 Oct 2000 09:54:35 Yog Sothoth wrote: if lame writes a 16 bit crc for every frame (using -p switch), doesn't that mean there are 16 less bits for sound data for each frame? couldn't that affect sound quality? is this getting carried away a little too much? :) On Thu, Oct 05, 2000 at 09:30:23PM +1300, Ross Levis wrote: -p -F will have no effect on sound quality. I have had mixed results with nspsytune. Ross. -- Michael Horan III Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MP3 encoding speed : LAME XING
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. I thought the difference was greater, but I had been dealing with mono files back then :) Owen. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Re:
Add the following proto-type just above the main() function int lame_decoder(lame_global_flags *gfp,FILE *outf,int skip); and you should be set Albert http://www.cdex.n3.net/ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - Original Message - From: "Nathan D. Blomquist" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 05, 2000 10:51 PM Hello LAME Developers, I was just wondering if anyone has been to able build the GTK version of LAME 3.87. I have tried with the makefile for MSVC and by using the project files. I have gotten the same error in both cases: c:\lame-beta\src\lame3.87\main.c(154) : error C4013: 'lame_decoder' undefined; assuming extern returning int This only happens, when I use the HAVEGTK option. I have no idea how to go about fixing this. Perhaps I have missed something. Has anyone else be getting this error? Thanks for any help, Nathan D. Blomquist http://www.win32lame.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] -q1
Hello Gargos, Thursday, October 05, 2000, 12:08:31 PM, you wrote: GC Have you tried using -q1 on fatboy.wav? It sounds significantly GC worse than -h or -q2. If you dont have this file let me know and GC I will send it to you. I agree that -q1 sounds worse on this one using "-V1 -mj -b128 -q1 -h" VS "-V1 -mj -b128 -q2 -h". Sad thing is that bitrate doesn't seem to be the problem here. Some more fundamental problem since the noise levels are very low (in db's), yet the noise is very apparent. "-q2 -h" is still worthless since it's poor sounding @260kbit/s :(. but you have a point, both mess up, q2 sounds better, yet far from good... I'm thinking the flaw is not with -q1 but somewhere else. the noise levels are lower than normal -V1 graphs, but relying more on the psychoaccoustics on this track would be the wrong choice. Maybe someone feels the urge to tweak the psycho-acc so this one will sound good @320 ? :)) LAME version 3.87 (beta 1, Sep 27 2000)(http://www.mp3dev.org) Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=1 32 [%.5]* 128 [ 5%] 160 [21%]* 192 [17%]* 224 [33%]** 256 [18%]*** 320 [ 6%]* average: 210.2 kbps LAME version 3.87 (beta 1, Sep 27 2000)(http://www.mp3dev.org) Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=2 32 [%.5]* 128 [ 3%] 160 [15%] 192 [ 8%]* 224 [ 7%] 256 [17%]* 320 [49%]** average: 260.3 kbps -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[4]: [MP3 ENCODER] -q1
Hello, Roel, maybe you should give these settings a try on that track: -V1 -mj -b128 -q2 -d -k --nspsytune --athlower -35 -X3 The bitrate stays pretty low (~224kbps) and it sounds very good... almost identical to the original. These are the only settings I could find that produce a smaller file than using 256kbps that still sounds good (actually it sorta sounds a bit better.. seems the noise is less harsh than that generated by 256kbps). I'd like to hear your thoughts on these settings. -- On Fri, 6 Oct 2000 00:28:06 Roel VdB wrote: Hello Gargos, Thursday, October 05, 2000, 12:08:31 PM, you wrote: GC Have you tried using -q1 on fatboy.wav? It sounds significantly GC worse than -h or -q2. If you dont have this file let me know and GC I will send it to you. I agree that -q1 sounds worse on this one using "-V1 -mj -b128 -q1 -h" VS "-V1 -mj -b128 -q2 -h". Sad thing is that bitrate doesn't seem to be the problem here. Some more fundamental problem since the noise levels are very low (in db's), yet the noise is very apparent. "-q2 -h" is still worthless since it's poor sounding @260kbit/s :(. but you have a point, both mess up, q2 sounds better, yet far from good... I'm thinking the flaw is not with -q1 but somewhere else. the noise levels are lower than normal -V1 graphs, but relying more on the psychoaccoustics on this track would be the wrong choice. Maybe someone feels the urge to tweak the psycho-acc so this one will sound good @320 ? :)) LAME version 3.87 (beta 1, Sep 27 2000)(http://www.mp3dev.org) Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=1 32 [%.5]* 128 [ 5%] 160 [21%]* 192 [17%]* 224 [33%]** 256 [18%]*** 320 [ 6%]* average: 210.2 kbps LAME version 3.87 (beta 1, Sep 27 2000)(http://www.mp3dev.org) Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=2 32 [%.5]* 128 [ 3%] 160 [15%] 192 [ 8%]* 224 [ 7%] 256 [17%]* 320 [49%]** average: 260.3 kbps -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
