[MP3 ENCODER] --mp3input
Hi, with "--mp3input" is the mp3 first completely decoded to raw and then re-encoded, or is there some frame-reshaping going on? a pub in the neigbourhood wants to encode 500 albums into both VBR -V1 and 192S. question of course is: is there a difference between: A) lame -V1 X.wav lame --decode X.wav.mp3 lame -b192 X.wav.mp3.wav out-A.mp3 B) lame --mp3input -b128 X.wav.mp3 out-B.mp3 ? It'd be nice not to have to encode the 500 albums twice. A too big quality sacrifice is not an option though. any opinions? thanks Roel mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Persistent JS problem, --nspsytune or not
Hello Naoki, Sunday, October 08, 2000, 4:55:50 PM, you wrote: Roel>> addendum: nonetheless JS influence or not, "--nspsytune" only has Roel>> negative implications on the -V1 (-q1) I use. Perfectly possible 128k Roel>> sounds better, just wanted to express that imo -V1 does not. Roel>> Roel>> I don't know what the cause is, but the improvements on lower bitrates Roel>> are at cost of sound quality degradation on higher ones. NS> I can't hear the joint stereo noise you mentioned. Maybe this is because NS> there is differences among individuals on perception of sound. So, I NS> can't fix it directly. NS> Since there is no problem currently in regular stereo mode, I believe the NS> problem is caused by (default) psymodel of joint stereo. NS> BTW, why do you stick to joint stereo? I think people who pays serious NS> attention to sound quality should not use joint stereo at high bitrate, NS> at least with current version of lame. Even FhG doesn't use joint stereo NS> at high bitrate. using VBR the advantages of JS far outweigh the disadvantages of JS. Velvet is for the moment the only track where JS consistently messes up. The noise is clearly audible and not in the >16kHz spectrum. Thing is I advice to use a headphone. Sennheiser HD-490 ($37)+SB128PCI ($25) makes it very audible. I am not the only person that hears this. I had quite a bit conversation about velvet with David McIntyre of QDesign trying to tweak their mp2/mp3 encoders on this track. All findings were confirmed. They only occur in the R channel. The distortions I talk about now are of the nature that anyone with the right equipment can detect them. It is not to put down all the hard work you put in -nspsytune, but I just wanted to signal that on -V1 this is a quite noticable quality degradation and size increase generally speaking. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[3]: [MP3 ENCODER] Persistent JS problem, --nspsytune or not
NS>> Perhaps you are hoping joint stereo to be improved, but --nspsytune NS>> doesn't improve anything with joint stereo. NS>> --nspsytune is intended to improve result of vbrtest.wav and square NS>> wave with VBR. You can obtain vbrtest.wav from website of lame. And, NS>> --nspsytune improves CBR quality at bitrate like 128kbps. Perhaps you NS>> can easily notice difference with result of appluad.wav. RV> thanks for the clarification. now I understand what nspsytune tries RV> to achieve. RV> I just asumed that it had something to do with JS because you told RV> that it wouldn't work with the RH extensions. RV> I guess the JS problem will be tackled at another time :) addendum: nonetheless JS influence or not, "--nspsytune" only has negative implications on the -V1 (-q1) I use. Perfectly possible 128k sounds better, just wanted to express that imo -V1 does not. I don't know what the cause is, but the improvements on lower bitrates are at cost of sound quality degradation on higher ones. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Persistent JS problem, --nspsytune or not
Hello Naoki, Sunday, October 08, 2000, 4:24:19 AM, you wrote: Roel>> I just tried on the version without extensions. I don't understand Roel>> the extra benefit of the nspsytune. Please explain to me what flaw needed Roel>> fixing in the older lame's and how you did it? I still find the sound Roel>> not good, and the file only gets needlessly bigger. NS> Perhaps you are hoping joint stereo to be improved, but --nspsytune NS> doesn't improve anything with joint stereo. NS> --nspsytune is intended to improve result of vbrtest.wav and square NS> wave with VBR. You can obtain vbrtest.wav from website of lame. And, NS> --nspsytune improves CBR quality at bitrate like 128kbps. Perhaps you NS> can easily notice difference with result of appluad.wav. thanks for the clarification. now I understand what nspsytune tries to achieve. I just asumed that it had something to do with JS because you told that it wouldn't work with the RH extensions. I guess the JS problem will be tackled at another time :) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Persistent JS problem, --nspsytune or not
Hello Naoki, Saturday, October 07, 2000, 1:00:29 PM, you wrote: NS> --nspsytune doesn't work correctly if RH extensions are enabled. I just tried on the version without extensions. I don't understand the extra benefit of the nspsytune. Please explain to me what flaw needed fixing in the older lame's and how you did it? I still find the sound not good, and the file only gets needlessly bigger. Maybe my standards are too high, but there is (and has been always) a serious JS problem on the velvet track (http://r3mix.50g.com): "lame -V1 -b128 -h -ms -q1": Sounds perfect to my ears. Average bitrate: 225,8 "lame -V1 -b128 -h -mj": rhytmic metallic 'static' noise over the complete length in the R channel. Average bitrate: 229,4 "lame -V1 -b128 -h -mj -q1": same rhytmic metallic 'static' noise over the complete length in the R channel. file is a bit smaller: Average bitrate: 223,6 "lame -V1 -b128 -h -mj --nspsytune": a much more disturbing kind of noise: it's alternating and sounds like some glitches. over the whole length of the piece and distributed in a set of 'bursts' of considerable volume. more sad news: Average bitrate: 245,4 On this track, the nspsytune does only have negative influence (imo). Not to be destructive or judgemental, but telling my findings is all I can do. Hopefully Naoki or someone has use for these. Respect and best regards, Roelmailto:[EMAIL PROTECTED] -- 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[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/ )
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[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: [MP3 ENCODER] Broken MP3s
Hello David, Saturday, September 30, 2000, 6:25:31 PM, you wrote: DB> I have a couple of MP3s which I encoded with LAME a long time ago. I made DB> the mistake of putting them on a Zip disk. Now they've got errors in them DB> which they didn't have in the first place, but Nero 4 is refusing to put DB> them on CD. Does anyone know if there's a utility anywhere out there which DB> could possibly fix them? 1- find the player that plays them with minimal distortion 2- write them to wav 3- burn the wavs with nero //r3mix.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[6]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
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, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[3]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
Hello Dmitry, Thursday, September 28, 2000, 1:34:50 PM, you wrote: D> nommx version was compiled with ic 4.5 (with project files) D> mmx version was compiled with makefile.msvc (ic4.5) D> may be here is the problem since the nommx ic version seems to output abberant data, could you please try and compile an ic version with makefile.msvc (ic4.5)? thanks! -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
Hello Mark, Thursday, September 28, 2000, 12:27:02 PM, you wrote: MP> On Thu, 28 Sep 2000, Gabriel Bouvigne wrote: >> # of S frames/ total # of M/S frames]. Room enough on the lines :) >> > > 4) Why does the MMX mode and non-MMX mode give different output on my >> > >Cel450/Win95OSR2? Isn't MMX supposed to give same results? >> > >> > On my Linux Box with a Pentium 166 MMX the MMX and non-MMX >> > version produce bit identical results. >> >> I compiled both releases (with and without mmx) with VC6, and the mp3 output >> is bit identical on my Cel460/win98. MP> Yep. Same output for both on my box. As Robert pointed out, it seems MP> Dmitry's win32 MMX binary has been compiled with Robert's extra RH_AMP MP> stuff, that he didn't compile into the non-MMX version. MP> Cheers. Hmm, so Robert: the "RH_AMP stuff" makes my files smaller and velvet better sounding in "-V1 -q1 -mj -b128 -h" mode. It was 3.87 MMX sounding better than 3.87 non-MMX _ic version. Both from Dmitry. I hope Dmitry figures out what went wrong, because most people download the binaries from his site. thanks guys! btw: what's the status on --nspsytune? I heard some fixes were made? Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
Hello, first some data: (-V1 -mj -h -b128 -q1) 3.86 (nommx) > Encoding c.wav to c-386-nommx.mp3 > Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG1 LayerIII ( 6.0x estimated) qval=1 > Frame | CPU/estimated | time/estimated | play/CPU | ETA > 12498/ 12498(100%)| 0:04:07/ 0:04:07| 0:04:07/ 0:04:07|1.3215| 0:00:00 > - bitrate statistics - > [kbps] frames > 32 9 (0.1%) >128 109 (0.9%) >160 1270 (10.2%) >192 4365 (34.9%) >224 2074 (16.6%) >256 1305 (10.4%) >320 3367 (26.9%) > > average: 235 kbs 3.87 nommx: > LAME version 3.87 (beta 1, Sep 26 2000)(http://www.mp3dev.org) > Win32 binaries from www.chat.ru/~dkutsanov/ > polyphase lowpass filter disabled > Encoding c.wav to c-ic-nommx.mp3 > Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=1 > Frame | CPU time/estim | REAL time/estim | play/CPU |ETA > 12498/12498 (100%)|3:25/3:25|3:26/3:26| 1.5855x|0:00 > 32 [%.1]* > 128 [ 2%]*** > 160 [19%]* > 192 [33%]** > 224 [13%] > 256 [10%]*** > 320 [24%]* > average: 225.8 kbps 3.87 MMX > LAME version 3.87 (beta 1, Sep 27 2000)(http://www.mp3dev.org) > Win32 binaries from www.chat.ru/~dkutsanov/ > polyphase lowpass filter disabled > Encoding c.wav to c-ic.mp3 > Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=1 > Frame | CPU time/estim | REAL time/estim | play/CPU |ETA > 12498/12498 (100%)|3:03/3:03|3:03/3:03| 1.7822x|0:00 > 32 [%.1]* > 128 [ 2%]*** > 160 [18%] > 192 [33%]** > 224 [13%] > 256 [11%]* > 320 [22%]** > average: 224.6 kbps remarks: 1) 3.87 MMX is smaller, yet it sounds better (???) (velvet JS noise) 1b)3.87 -V1 is 20% faster than 3.86 (thanks Robert!) 1c)3.87 -V1 MMX is 35% faster than 3.86 (thanks Takehiro!) 2) I miss the # of frames in each bitrate mode. The new real-time % data looks really neat, but please re-instate the # frames. 3) Would be really something if it would also say [total# frames/total # of S frames/ total # of M/S frames]. Room enough on the lines :) 4) Why does the MMX mode and non-MMX mode give different output on my Cel450/Win95OSR2? Isn't MMX supposed to give same results? thanks and Best regards, Roel mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] Ogg Vorbis beta 2 still has a long way to go.
M> Anyway, he apologized, I apologize, we were on the bad crack today. We can M> finish this up over some beer or good single malt. I feel this 'urge' to let everyone on this list know that I think beer is a poor man's drink. ;)) Roel - the best barfight in the northern hemisphere [curious thing is I never seem to offend any ladies on this list] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] Ogg Vorbis beta 2 still has a long way to go.
Hello Joshua, Thursday, September 14, 2000, 10:53:19 PM, you wrote: JB> No one asked your opinion about Ogg Vorbis, so why tell everyone JB> on an *mp3* encoder mailing list your feelings? justified comment. someone did ask my opinion, and I knew the people I needed to reach are all on this list. the list is not mine, hence my mistake for using it so. mix of stupidity and rashness on my behalf. JB> Here's my opinion, you're an asshole. But that's my opinion, so I guess it's JB> ok to say it. The main difference is I will repent and work things out with Monty and Jack by helping them with OV. Something gets served. I know I am arrogant and act on sentiment. It takes a very arrogant person to set up a site claiming "the truth about mp3 quality", and actually getting away with it. Owing to this, I don't connect with some persons and indeed they will never find me more than an asshole and my opinions of no value. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Ogg Vorbis beta 2 still has a long way to go.
Hello Jack, JM> Your other comments aside, this is just plain FUD. sorry, I don't understand "FUD". Nor "FWIW". JM> We have top notch lawyers on this. We have done lots of patent JM> research. We have paid lawyers to do lots of patent research. If you believe OV is a match for the mainstream music and distribution industry, no problem. I know what is crippling mp3, and I hope your project does not get struck by the same. JM> I'll remind you that MP3 IS currently crippled by intellectual property JM> restrictions, and Vorbis is not. The only reason you don't have problems like mp3 has, imho, is because mp3 IS mainstream and has a multi-million user basis, Ogg is, till date, a quite obscure format in alpha-beta stage. Once OV threatens the establishment your legal team of experts could have much to do. JM> Why you'd even bring this up (since all JM> your other arguments are vorbis vs. mp3) is beyond me. It makes little JM> sense. ... JM> including yourself to improve the quality of vorbis. We're not here to JM> kill the LAME project. I know my arguments show that I feel threatened, but I'm not. I'm equally critical towards lame vbr-new for example. JM> Also, remember that vorbis has dual stereo, and doesn't combine JM> channels. It's not fair to compare join stereo against it. Do your tests JM> with dual stereo and see if the results are the same. Help us tune JM> it. This feedback cycle with you is really lousy, IMO. We release JM> something, and then 2 months later you tell everyone it sucks. (I just finished some exams, so only now I had the time.) I didn't say 'it sucks', I just said that it's still no "archive quality". Then an expression like "it has surpassed lame quality wise" is a bit unreal (more 'hype') It is, as Monty says probably some bugs and imperfections that need tweaking, and I'll gladly help out on some tests. I'll get on the Ogg list, and offer my services there. JM> I also don't see why it's JM> some kind of "invader" on your personal space or something. We're JM> building something for everyone. it's open and free. Mp3 is not. I know I'm too sceptical about these things. I've cut myself in the past with non-mp3 alternative codecs (PAC/lucent), and was left with a DB of unusable music. JM> I'd JM> think you'd be just a little more enthusiastic about helpingi it develop JM> into something you're happy with. I'm just not so optimistic about your legal strength. The fact that OV needs a lawyer, marketing and has a person on the payroll to promote a "free format" leaves me a bit suspicious. It's a good thing to be able to persue your hobby in a paid fashion, but I've seen it turn an objective and respectable person (KM) into a person with "intrests", and before I knew it he did no more objective tests, but lobbying had become his main concern. Hence my reservedness. I always felt Ogg tried to "sell" itself. I know, and am guilty myself, of liking attention and being happy to express my opinions to an audience. I am probably wrong about this, but having a public face stating: all in control, and then privately asking leniency "because it's just beta" is hard to grasp. LAME has never claimed to be the best. Ogg has. (that about sums it up) JM> It will take vorbis a while to mature as well, but it's JM> pretty damn good now. popularity contests never were my thing, Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Ogg Vorbis beta 2 still has a long way to go.
Hello Monty, (first, I did not know you were the developer, nor did I know you did almost all the work on this) Thursday, September 14, 2000, 9:05:13 PM, you wrote: >> The best thing so far about Ogg Vorbis has been the marketing. M> That's at best inflammatory, Roel. Why not just start off your next mail with M> a few comments about my mother? :-P my apologies, is a harsh in retrospect. should have thought a few moments instead making this statement. cause was my own frustration being let down by OV. I sometimes have the idea everyone looses their head with this format, mainly because of the hype, but indeed this remark was not called for, non founded. >> I tested one file with the new b2, and even with -m6, the best possible >> Vorbis setting, resulting in a 350kbit/s file it sounds poor. M> Then that's a bug. You're still going to be able to find problem samples M> (and how many samples does it have no problem with at all? The vast majority) it's unlucky that this was the first sample I tried on it. it is one of the hardest I have, but if I test an encoder and it has audible artifacts on this, I automatically disregard it as "archive quality". I never said that there is no quality difference between b1 and b2, but I find OV not good enough yet. I'm convinced it will be eventually. M> Last time you gave us the problem samples, and we fixed it. We'll do the same M> thing this time. correct M> Isn't that the whole bloody point of a beta release? I agree. My main concern with OV is that it has the reputation of being a finished good product. Beta1 was far from, and you probably fixed a lot since. Beta2 fumbled up on the first track I tried, so probably I did not give it a fair go. >> There are obvious low-frequency bass distortions, which mp3 at >> 256kbit/s bitrate doesn't show. M> Right, bug, checking it out. Most likely, it's the +/- 1.5 dB resolution in M> the current codebooks. If you think I can help with something, I'd be glad to help out. I offer myself as a testslave for the next week, as a matter of compensation for the harsh critique. >> Maybe they should have developed their product for 1-2 years before >> setting up a website and featuring artists. M> Ahem. I've been working on this for seven years. sorry, is just my opinion. the music encoded with beta one whas of such quality I would never use it myself. M> Seven full time years, on my M> own, after the duties at my day jobs were finished. I've got the good fortune M> to be funded now, so this *is* the day job. These past six months of funding M> are all you're apparently aware of. Now if you could bother checking some of M> your rant against reality before insulting my dedication, I'll consider not M> stuffing you onto my shit list for all of eternity. There was an Ogg Vorbis M> *long* before there was a LAME. >> (*) One of their main developers stating "the ogg encoder available as of >> today (beta 2), does sound better then current Lame." does their cause >> not much good. M> I stand by what I said. it's just: we disagree on this M> I'm an audio asshole who isn't here... :) >> Believing OV, once mainstream, will not be slapped and crippled by lawsuits from >> conventional music and distribution industry because it uses no >> obvious patented material is plain out naive. There goes the biggest >> advantage of this format. M> "Bah". Diatribes are not productive. "?" -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Ogg Vorbis beta 2 still has a long way to go.
Hello xxx, Thursday, September 14, 2000, 8:54:20 PM, you wrote: xx> Your comments are outright cruel. They edge on being completely xx> non-constructive. Yes, the comments are very direct. It's just: I keep getting mails from people telling me that OV b2 is out, and that many bugs are fixed, and that it is claimed now that OV outperforms mp3 quality wise. Then I test it, and on the first clip I use, I have obvious audible artifacts. I know that it might not be politically correct that I am this conservative, and I should be more supportive of the new patent-free format, but I have this whole "hype" feeling about the whole project. It was not even alpha, and it was on slashdot as "the mp3 successor". I like innovation, and I never intend to hurt anyones feelings, but I am honest about my findings. It's just my sceptical person that is quite harsh in outlet, but I'm just critical on all my tests, so why should I have sympathy for this format? If I had to choose a good alternative format to mp3, it'd be that mp+ I tested briefly recently: very good on all I let it encode. OV is promising, but I still think it has a long way to go to be "better" than mp3. Perfectly possible it sounds better at 128k or so, but for archiving purposes it simply isn't good enough yet. xx> I'm sure that no one will benifit from your attacks. probably not, but being able to have a different opinion than the mainstraim one, and being allowed to express it isn't a bad thing. I'm always open to founded and motivated critique myself, so please. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Ogg Vorbis beta 2 still has a long way to go.
The best thing so far about Ogg Vorbis has been the marketing. I tested one file with the new b2, and even with -m6, the best possible Vorbis setting, resulting in a 350kbit/s file it sounds poor. There are obvious low-frequency bass distortions, which mp3 at 256kbit/s bitrate doesn't show. Since OV developers also read this list, I'd like to let them know to tweak their encoder to have good encoding of 'velvet', which can be found at http://r3mix.50g.com LQ5-AAC manages to sound very well @192, so in future before they come stating again "better than lame" (*) -> at least try get this track right at 192kbit/s. Maybe they should have developed their product for 1-2 years before setting up a website and featuring artists. It simply still is too buggy and needs a lot of work. (*) One of their main developers stating "the ogg encoder available as of today (beta 2), does sound better then current Lame." does their cause not much good. I'm just not very good with "hypes". OV might get there, eventually. [my opinion] Believing OV, once mainstream, will not be slapped and crippled by lawsuits from conventional music and distribution industry because it uses no obvious patented material is plain out naive. There goes the biggest advantage of this format. [/my opinion] -- Best regards, r3mix.net/Roel -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] MS switching
Hello Gabriel, Monday, September 11, 2000, 5:43:55 PM, you wrote: >> I am fundamentally agains crippling an encoder to fit the needs of an >> inept decoder. If 320 is chosen by LAME on -V1, it is there for a >> reason! GB> This point is debatable. GB> I am in the clan of the people using -B 256, and here is why: I choosed to GB> keep strict ISO compatibility I didn't know ISO only allowed up to 256. Then I understand you. It's too late anyway for my huge amount of vbr albums, so I guess I'll have to buy myself a player anyway that supports up to 320. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] MS switching
Hello Frank, Sunday, September 10, 2000, 11:38:40 PM, you wrote: FK> This model is much better than the hard switch to forced LR frames. I agree that JS has benefits. Big issue was what your criterium will be. FK> Currently there is a lot of music out there where 160 kbps with default FK> settings has the same or less quality than 128 kbps. Ditto 192 sounding poorer than 128. Mostly high-queeling artifacts due to JS. FK> The 160 coding suffers from the lack of MS frames. Stereo separation is a FK> little bit better than the 128 coding, but there are a little bit more FK> distortions. The 160j coding sounds not perfect, but a lot better. Try the Velvet track on http://r3mix.50g.com . Try 192S VS 192JS. There S sounds acceptable, while JS totally messes up. You see? you find some cases of the one, I some of the other. There simply is not too much logic in this. I agree that something could be done to the JS issue, but while you try to tweak current criterium for case A, it'll worsen for case B and loose generality. Simply encode both the MS as RL frames, and measure afterward which one introduces least artifacts. I think measuring distortion like VBR does is a good way to start. It would be a general approach for all bitrates, for all music pieces for cbr96, cbr256, vbr9 and vbr1. If you work with static extra leniences, it would work for some pieces on the bitrate you had in mind, but for example it would be worthless for someone using -V9. >> what is the use of sacrificing kbits in trade for assumed quality >> gains? There will always be pieces where even -mS 100 will not be >> enough, and you loose a lot of the use of JS. >> FK> Currently we have total loss of the advantage of MS for bitrates > 128 kbps, FK> even on digital mono files (L and R are 100% identically). I don't understand how you can conclude that? FK> Pro/Cons LR: FK> + more constant and predictable bitrate than MS FK> - often higher bit rate demand than MS yep FK> Pro/Cons MS: FK> + often lower bit rate than LR FK> - very unpredictable and varying bitrate, so sometimes you FK> must switch to LR which it doens't at the moment. It says: MS nomather what if criterium ok. (FK> - switching artefacts) want to see more on this. FK> The best parameter you know after coding, for instance: FK> OptionAdditional Info after coding FK> -b256 * nevertheless use MS, there are nearly no problems with MS, mask and FK> signal correlation is high, so NMR can be increased by "-mj" I disagree. Once I saw what JS could do to 192, I stopped advicing people to use JS on 256. It's supposed to be ok, and the current JS model, nor what you suggest, has no way of guaranteeing it will sound better than S. FK> -b128 * use LR, there is nearly no advantage of MS frames, only low FK> signal correlation, masks are often very different, reduce FK> upper frequency limit from 15 kHz to 14 kHz ? I quote: FK> Currently we have total loss of the advantage of MS for bitrates > 128 kbps, FK> even on digital mono files (L and R are 100% identically). ? sounds contradictive to me. I for one believe MS usage can be beneficial in _all_ cases, yet there needs to be a check if it didn't hurt quality afterward. If you could get the encoder pick the best out of LR or MS, both our problems would be solved. FK> -V0 * file size is increased by 1.2% by setting -b128, so use this option FK> * only two frames are 320 kbps, so also use -B256 to avoid problems FK> with some players I am fundamentally agains crippling an encoder to fit the needs of an inept decoder. If 320 is chosen by LAME on -V1, it is there for a reason! Or you try to archive using mp3 => best quality, no compromises, use VBR for size benefit Or you want to have a practical size file for a portable player or so => do whatever you want, even take WMA@64 -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MS switching
Hello Frank, Sunday, September 10, 2000, 6:39:22 PM, you wrote: FK> But there are no controls to affect the switching more sensitively. FK> So, for instance, a switch can be added to set a penalty bitrate for FK> the MS coding theme: FK> -mS 10 use MS coding if it saves 10 kbps FK> -mS 20 use MS coding if it saves 20 kbps FK> -mS 200 use always LR coding scheme this is just what I was afraid of: fighting symptoms instead of a fundamental change. (-mx thread) what is the use of sacrificing kbits in trade for assumed quality gains? There will always be pieces where even -mS 100 will not be enough, and you loose a lot of the use of JS. An algorhytm needs to be adaptive: you put in music, and what comes out should be the best possible: M/S or LR. If it takes encoding all double and measuring distortion or so, it takes encoding all double. I'd still prefer it than a patched-up fundamentally inept model. With all these settings, won't you loose a great deal of universality? Why not look more at JS (-mx) as a sort of variable switching algorhytm , like vbr-old iirc, rather than a, becoming increasingly complex, condition to switch to MS. Adding -mS xx will weaken the benefits of JS (saving space), and what is there to gain? A hack for some music pieces, while you're even further off shore since you're left a less powerfull algo with still no form of assuring quality. just my 2c, not trying to stop a creative process, but simply giving my reflection on this. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Lame re-sampling bug?
Hello all, this is a forward of a thread on http://bboard.mp3.com/mp3/ubb/Forum1/HTML/003127.html : OK, I gave in and did a quick resampling test. It shows why you shouldn't use lame to do your resampling. Here's three plots. 1) Original signal. 2) Resampled via Cool Edit, 3) Resampled via lame. http://privatewww.essex.ac.uk/~djmrob/mp3board/orig.gif This is my original test signal. You're looking at a spectral (frequency domain) plot. The time axis is samples. There's an upward tone sweep, some very quiet tones, then a downwards tone sweep with an 18kHz tone mixed in with it (the crossing green lines on the right). http://privatewww.essex.ac.uk/~djmrob/mp3board/cep.gif This is the test signal resampled to 32kHz by Cool Edit Pro, using the highest quality setting (999). Basically, you have what you had before, minus the stuff that was over 16kHz (which can't be represented in a 32kHz sampled system - Nyquist theorem). The background noise is slightly higher than I'd like (-84dB rather than -96dB - possible in CEP if you go into the 32-bit domain to do the resampling, then dither back to 16-bits), but overall, it's a pretty good resample. http://privatewww.essex.ac.uk/~djmrob/mp3board/lame.gif This is the result of the same resampling process, carried out by lame. As you can't just resample in lame, I used: lame --resample 32 -h -b 256 orig.wav lame.mp3 then decoded the mp3 using Winamp 2.22. You get the same thing encoding at 320kbps too. As you can see, lame adds some severe aliasing distortion. At it's worst, it's at about -24dB. The original sine wave was at -6dB. The distortion is at 14.5kHz which means it aliased from 17.5kHz - therefore whatever anti-alias filter lame is using has a -18dB rejection ratio at 17.5kHz. It should be down to -96dB or lower by then. What does this sound like? Well, on a simple test signal like this, the most audible problem is that as the frequency of the test tone increases beyond 16kHz, rather than continuing to increase beyond the range of your hearing, it starts coming down again. The ultrasonic part you shoudln't be able to hear is reflected back into the region where you CAN hear it. This is bad. The other problem is that you're effectively adding spectral components to the signal. This makes the job of an mp3 encoder harder - which ones should it discard? I used lame 3.86BETA for this test. CEP took 1 minute to resample this 20 second test file. By using a lower quality setting (256), it can do it in real time, and still do OK. Lowering the quality (increasing the speed) further degrades its performance. Lame can resample AND encode the signal in 9 seconds, which explains why it does such a poor job. Maybe someone working on lame can add an optional high quality resampling routine? Can someone on the mail list suggest it? Hope this is some interest. If it's not, ignore me! Any questions are welcome. David. http://www.David.Robinson.org/mp3decoders/ The truth about mp3 decoding quality updated. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[3]: [MP3 ENCODER] RazorLame 1.1.0 released
Hello Holger, Thursday, August 31, 2000, 2:31:48 PM, you wrote: HD> It's hard to come up with a good option dialog for RL, given the vast HD> amount of options LAME has to offer. I think it's a good idea to put HD> those settings in categories, however, I agree, it can get a bit HD> unclearly... I think this is not good way of handling things. If there are too much options, there are too much options. If you decide to catalog some of them as "advanced", some as "expert" and other with another subjective label, it only complicates things even further. 30 options in 1 screen are less complicated than 30 options scattered over 5 screens. What I suggest, since lame will continuously develop and new options will be added, is to simply handle things like this: - 1 screen (oversight & clarity) - in top, a (greyed out or so) continuous display of current command line. I never understood why enabling this is an option. - only a limited set of "core" options. stereo mode, bitrate, encoder mode, delete after, and the most common flags. Just so you have a nice oversight of options. - a box to add non-common command line options. - a flag to make lame only use that box, instead of adding the content to current selected options. This is, basically, the way lamebatch did things. In the long run this seems to be the only managable way of constructing a frontend imho: You simply see what's set, and you don't need to look 3 windows back for some setting you also might need. then, why no multithread? it'd be nice to update the to-be-encoded list in one window while the encoding-box is somewhere else... I had to press abort too often :( just some suggestions ... -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] RazorLame 1.1.0 released
Hello Holger, Thursday, August 31, 2000, 11:32:13 AM, you wrote: HD> just a quick note that I've release final version 1.1.0 of RazorLame, HD> available from http://www.dors.de/razorlame/ I tested the 1.1.0 yesterday, so I think it's still the beta, but it works like a charm for me. If I had to give 1 comment: please make all those settings appear on 1 big page because it's very unhandy to go and look for some options in a few different windows. (Now 'delete source file after encoding' is in the "advanced window", and also I use some from the "expert" window. Would be a lot handier and surveyable if it were in 1 big window like in lamebatch. Also would limit the explanation how to use RazorLame on r3mix.net a _lot_ easier. Maybe also the ability to add files when encoding already? now I must abort the current session to add new directories. (I rip and encode simultaneously) Maybe also a "scan subdir" for files or so. I just encoded Directory van E:\The Grateful Dead - So Many Roads (1965-1995) (5cd). CD108-30-00 4:52p cd1 CD208-30-00 4:52p cd2 CD308-30-00 4:53p cd3 CD408-30-00 4:53p cd4 CD508-30-00 4:53p cd5 and for a lazy *** like me it's a whole lot of unnecesary work to add the 5 dirs manually :). btw: why are mp3's shown anyway when I choose "encode"? I think only showing .wav by default would be better? But anyway, still the best program around, cheers, Roel/r3mix.netmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] I have HUGE Different MP3 and WAV-original
Hello alexram, amr> I have huge Different between Orginal Wav and MP3. what do you mean by that? I'm listening to the 4 clips pasted together, and I cannot really keep them apart. (been looping for 15 minutes now, nice groove) All four filled with noise. what's the "huge difference"? in listening? amr> See please IT at http://www.nmz.natm.ru:8101/mp3/1.rar amr> 670KB amr> And give some Advice please! try "lame --decode" before comparing the mp3's to the original wav.(?) - or your player is really bad at decoding mp3's - or mp3 isn't just for you. you have seriously superior hearing, in which case I'm wondering why you even boter with 160kbit/s (or noisy tapes)? maybe http://www.monkeysaudio.com is something for you. amr> Alexander amr> Russia Roel Belgium -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Another lame quality opinion
Hello all, picked this up on: http://bboard.mp3.com/mp3/ubb/Forum1/HTML/003127.html author is Timothy, someone I respect the opinion of. I must say I pick up other artifacts, so maybe this is valuable. :) > Hi all, > I've done some more listening tests and these are merely > subjective. > > First comments are regarding the famous command line: -V 1 -b 128 -m > j -h > > Well, the same comments that I once had are again the same feelings > upon listening. Joint Stereo still leaves out certain spacial depth, > "presence", and lower midrage/upper bass filling. The sound in the > midrange sounds accurate, the highs have no apparent artifacts. In > my strong opinion, I'd say that it's damn near impossible to hear > artifacts on most material encoded with this command line on many of > the most recent LAME versions. VBR is doing a good job, but not as > good as I feel it could. As far back as LAME version 3.58, I > remember complaining that the lower mids and upper bass sounded thin > and the highs were dry as a result of that thinning (while using > joint-stereo). The same analogy applies now as then in my critique > of the most recent LAME versions. > > Comments on the "dry" factor. It seems localized with the > joint-stereo mode only. It's the only contributing command line > factor regardless of how hard I tried to get around it with > different settings and experimental modes. Only bitrates of 224 > kb/sec and higher can make joint-stereo sound "full" at the bottom > end of the sound. Also, stereo image seems to be missing certain > cues at times. Imagine hearing a sound position left, right, and > then center. Now, imagine a sound that is left of center, but not > quite left. The joint-stereo mode seems to put this sound to the > center very often for no reason, other times it does the job > correctly. This seems to leave gaps at times when certain > instruments/sounds pan or fill up the sound image. It's not very > apparent, but it's there if you critically listen on good speakers. > I found this anomally while trying out orchestra music which carries > many spacial cues. Again, as always, the point of transparency for > me is at 224 kb/sec either in VBR average or CBR mode. LAME does an > admirable job with joint-stereo at the middle bit-rate averages, but > it's not transparent to me. Every frequency range seems to be done > justice except in the lower mid-range/upper bass area. In stereo > mode, it sounds fine at any bit-rate, even the artifact filled 128 > kb/sec range. > > Achieving "Fullness" with joint-stereo should be a priority for the > LAME team. Even with -V 1, the problems is there. > > Some suggestions maybe that could work: > > -Allow joint-stereo to select more "stereo" frames. Maybe put in a > new criteria for selection of the modes within js. > > -I recommend that sf-band 22 be cutoff while using 160 kb/sec in CBR > mode as a default. My reasoning for this is that artifacts can still > be heard at 128 kb/sec CBR, and this stands to reason that artifacts > exist in 160 CBR. The difference is in the available bits. At 160 > CBR, a removal of sfb 22 should allow enough bits for > near-transparent sound up to 15KHz. That is a more appealing middle > ground for that bitrate. > > -Please insert a command line option to completely disable sfb-22 > (16KHz-22KHz), not just a lowpass filter option, but an option to > disable sfb-22 completely and insert a 15.5KHz filter. The reason > for this is that some users might like to try and test out the > removal of high frequencies to see if audible resolution improves at > certain bitrates. You can use it as an "experimental" option. Also, > in this experimental mode, can you re-structure bit distribution to > "fill-in" areas like lower-mid range scale-factor bands? I'd like to > experiment with this option more fully, especially in joint-stereo > mode. > > -masking and noise thresholds could use more improvement. Using LAME > 3.86 (-V 1 -b 128 -m j -h) I encoded Pink Floyd - Money (off the > Dark Side of the Moon album). Around the 3:00 mark, a set of guitars > solo (famous moment too). I referenced an old mp3 of this that I > made with LAME 3.36 in full stereo and VBR 3 mode. I compared the > mp3 made by LAME 3.86 in js mode, the mp3 made by LAME 3.36 in full > stereo mode, and the original wav file. Here are my results: > > -The LAME 3.36 mp3 was superior in terms of masking noise and > maintaining quality on the guitars when compared to LAME 3.86 in js > mode and using the wav file as a means of comparison. LAME 3.86 was > "tinty" or "tinny" sounding. Any metallic clink or clack was > over-emphasized and seemed tinty, not full. Vocal sybillances were > alos emphasized in the high frequencies. > > -The LAME 3.86 mp3 in js mode was flawed. I could hear a static > (crackling white noise) sound on the guitars during certain moments. > Clear noise that wasn't in the original wav file or on the LAME 3.36 > mp3. This must have been a masking
Re: [MP3 ENCODER] lame fails tests?
Hello Bart, Friday, August 25, 2000, 5:49:31 PM, you wrote: BK> anyone can explain this? I've done so >10 times to people that write my site (r3mix.net) maybe it's time to ask the author of that (old) article to write reproducable test with more founding. to his ears 128k lame sounded worse than FhG. Perfectly possible I think, but what it has to do about lame failing I don't know... -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] the "-mx" mode - more different philosophy
Hello Mark, Tuesday, August 22, 2000, 9:18:22 PM, you wrote: MT> Problem is, this is a lot of work and it is not clear that it would MT> really improve things. does it mean anthing if I say it will? :) MT> The hard part is how do you tell if M/S gives MT> better results than S? The only way is by some measure of distortion MT> - allowed_distortion. But as we know, all measures of distortion are MT> just very rough guidelines - if they were really good, VBR would be pefect! As you might know, I've been doing extensive tests on noise graphs the last two months. My conclusion is that the VBR of lame is _very_ good. Check out the graphs of different encoders at this page: as you can see, the current noise-calculations of VBR seem to do what they're intended to: minimize noise. The -V1 mp3 is actually closer to the original wav than the 256S is. Does the VBR sound better? Well, no, but I'm convinced the reason for this is the shortcomming of the -mj mode. I know you've always been very sceptical about VBR, but on the other hand the fundamental shortcoming in JS is less of a concern? I don't understand: How can one expect a simple MS-qualification formula to predict how a frame will come out sounding? Like you say, and I agree, the guess is ok for let's say 95% of the time, but 5% is a very high failure rate in this field. I don't want my tracks to sound ok,95% of the time. I want it 100%. (within the constraints of what is physically possible with mp3) The only way to have some sort of quality guarantee, is to check the frame after encoding. I agree with Robert that the current -mj should be tweaked in the conventional way. MT> Thus my fear is that if we use some function of the distortion, we MT> will not be able to tell in a reliable way if mid/side sounds better MT> than stereo. I'm sure even the current "rough" formula would be enough to safeguard from current exploits. The reason I'm convinced of this lies herein: At current, the (extremely likely) reason the JS vbr file runs up in bitrate is that the current distortion-meter used to determine acceptable distortion actually works! Let's put some things together: I've got a 192S file sounding ok I've got a 192JS file sounding bad I've got a -V1 S sounding ok I've got a -V1 _sounding ok_, but with remarkably larger number of 320 frames. This suggests that: current noise calculations on the VBR picks up on the JS distortion, and compensate for it! (otherwise the -V1 -mj would have sounded bad) now instead of compensating by making the bitrate higher, you could try the S-frame alternative. Lame VBR is the best in the world. Thanks to your and others' work. MT> Here is what I would suggest: MT> (I've done this many times: it is tedious and a lot of work!) my point exactly :)) MT> Can you isolate the problems in velvet.wav to a few frames, and then MT> skew the average downward. Thank you for the great explanation. I will look into this asap. I'm doing some exams this week, so time's very limited at current... .. I think this issue should be looked upon _long-term_. We both recognize that the current -mj implementation does not give one guarantee of good quality. Instead of spending countless hours (what you also recognize) trying to fight symptoms, why not build up an approach like -mx that measures instead of predicts? * Who is to say that a tweak to the M/S conditions to fit "velvet"-needs will not have negative implications on other clips? * What's the impact of these current -mj files where, once a minimal requirement is met, M/S is defaulted? I get files with >90% M/S frames. Does this "feel" natural? Wouldn't it be more credible if you'd get a file with a more mixed distribution of S-M/S? * tightening the M/S-allowed condition, will undoubtedly decrease the potential gain in available that can be harvested with -mj mode. (say you tweak -mj to get that number of 35% M/S frames in Velvet even lower, to the point where the artifacts are gone) (* are you sure about the quality implications of rapidly switching S-M/S?) * how about <112kbit/s frames? Shouldn't the predictive model be (more?) adaptive to different bitrates? * What if you'd optimize your psycho-accoustics? How would this impact on your prediction model? You get the point? All these uncertaincies can be resolved quite simply: introduce a measuring-based model rather than a (increasingly complex) model based on "assumptions". I can only speak for myself, but don't you feel a curiosity how such an -mx mode would act? _What if_ it returns 50% S frames where the current model returns only 5% of them? Would you reshape your opinion then? Maybe it would make -V8 sound acceptible? Maybe it would drastically improve 128kbit/s encodings. I think most of us would actually be very surprised of what results might actually come out of the "computer". I'm not asking to cast out certaincies, but I'm asking relief for all the uncertaincies. -- an
Re[4]: [MP3 ENCODER] the "-mx" mode - different philosophy
Hello Gabriel, Tuesday, August 22, 2000, 3:59:45 PM, you wrote: GB> I'm not equiped for listening tests here (only an awe64) GB> , but is the velvet GB> problem the thing I'm hearing in the right channel? (or am I thinking I'm GB> hearing something?) I have $25 sb128 pci and $38 Sennheiser HD-490. With a headphone on decent volume, you van indeed hear the R channel behaving strangly. GB> If this is the case, it seems to me that it's reduced in -mf, but the GB> stereo image is also changed by this switch. GB> If it's gone in forced mode, it could be a toggling problem. Roel, could you GB> check this? It's hard to tell. I also did the lame -mf, but this introduces other artifacts as well... I think there still is need for a "-mx" mode, because the velvet is merely one of the symptoms of an inept -mj. I encourage to improve to MS in -mj, but inherently -mj will always be inperfect. Instead of spending countless hours tweaking MJ in such an inefficient way, maybe try to use the benefits of -mx to improve -mj. (at least I think so :)) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] the "-mx" mode - different philosophy
Hello Gabriel, Tuesday, August 22, 2000, 12:43:07 PM, you wrote: GB> First, please note that it has been a long time I didn't really looked GB> inside of the Lame code, so I'll perhaps tell a few wrong statements. (btw, GB> please could anyone explain me when to use the word "tell" and when "say"?) I hope you don't expect english advice from me :)). >> If I understand correctly, the "-mj" is evaluating if a frame >> qualifies for M/S coding beforehand, and if so, it will then be coded >> in M/S, independent of the outcome. GB> There is also another parameter: trying to minimise the toggling between s GB> and ms if this really is necessary, this condition could be left in (even the current M/S criterium), but because the "-mx" will get results from experiment, I'd like it to cast as much as possible predictions. Just let it "compute" and take out the best one. If, of course, this kind of excessive toggling is a decoder problem, it'd need to be a criterium to be met in the encoder. If not, just let the encoder encode, and pick out the frames with lowest noise... >> I've heard my fair share of examples where lame opts for M/S, but >> afterwards this is a bad choice, giving a M/S frame sounding much worse >> than S would have, or in vbr, more bytes are used on the M/S frame >> compared to the S frame. GB> Does this really happens in vbr? Could you please try using Mp3x and see if GB> the same frame could sometimes use more space in ms than in s? I have more than an educated guess when it comes to this. btw: could someone update that stats display on the end of encoding? I'd like a counter of how many M/S and S frames are in each bitrate. Much easier and fast than using Mp3x. GB> It seems so strange...If it's true, I think that there is a mistake somewhere in the ms GB> bit allocation why is it so strange? Is it feasible that a reasonable simple formula to determine if a frame is fit for M/S is able to _exactly_ predict how it comes out after encoding? It can never do so 100% accurately. to make my point, let me quote Mark Taylor himself: (about JS) > This works much better than the algorithm suggested in the ISO MP3 > spec. But you still run into trouble: what if 90% of the bands can > handle mid/side encoding, and 10% cant? LAME has to make a decision > in these cases, and it is possible it can make the wrong decision. It is proven quite clear to me in the Velvet example: - Sounds _fine_ in 192S (-ms) - Totally flunks in 192JS (-mj) so, even if the JS sample only has 35% M/S frames, this still is obviously too much because the M/S are there while the S ones would be a clearly better choise. With this in the back of my head, I looked at what vbr (-V1 -q1) did on the same sample: Joint Stereo 320 113 (24.8%) Stereo32099 (21.7%) I know there more possible causes (bit-reservoir conditions etc) for this behaviour, but this would be very unlikely. (because the bitreservoir: one time a JS frame is bigger, another the S would be, cancelling out each-others effects in the long run) So let's interpret this in the most simple way: * we know M/S makes mistakes on this sample (192 cbr) * #JS 320 frames > #S 320 frames educated-guess: Lame opts for M/S for the same reason it did on the cbr case, but after encoding, it ends up with very big amount of intruduced noise -> high framesize, and maybe even maxxes out @320. This while the whole time it would have been better of with a 256S frame or so ... >> problem: once the criterium is met, and a frame tagged as >> "M/S"-material, it will always be a M/S, even if S would have been >> better. GB> Not always: I think that if we got something like s-s-s-ms-s-s it will be GB> converted before bitstream formatting to s-s-s-s-s-s in order to reduce the GB> togling artefact. In general. Or practically: much too often ;) >> Big advantage of this prediction method is the speed. GB> I don't know if it's still the case, but in the past both ms and s data were GB> computed as the mode of a frame could be changed according to the next one. that would be nice >> Since you never have 100% accurate prediction this is one of the most >> prominent causes of poor quality in -mj mode. (read that post >> of me referring to 192JS of the Velvet track) GB> This Velvet track must have some (perhaps not yet known) other difficulties, GB> as the results are quite catastrophic for every encoder, including mp2 ones. Lame 192S sounds fine, also -V1 -q1, but I'm thinking it's unnecesarely too big... >> What I'm suggesting: a "-mx" mode (or whatever letter) GB> This is, to my mind, the goal of -mj, so any change should be made into -mj I disagree. Initially I was also thinking this, but then when I discussed all these alledged improvements, I found a healthy amount of reservation to this idea because of the big implications. Suggestion was: the M/S prediction needs tweaking for this problem-wav, rather than changing the whole system. And, in re
[MP3 ENCODER] the "-mx" mode - different philosophy
Hi, After a whole lot of testing and listening it came to me: "-mj nor -ms" are optimal quality-wise. * -ms unnecesarely wastes bits most of the time * -mj has M/S making too much unnecesary mistakes: If I understand correctly, the "-mj" is evaluating if a frame qualifies for M/S coding beforehand, and if so, it will then be coded in M/S, independent of the outcome. I've heard my fair share of examples where lame opts for M/S, but afterwards this is a bad choice, giving a M/S frame sounding much worse than S would have, or in vbr, more bytes are used on the M/S frame compared to the S frame. problem: once the criterium is met, and a frame tagged as "M/S"-material, it will always be a M/S, even if S would have been better. Big advantage of this prediction method is the speed. Since you never have 100% accurate prediction this is one of the most prominent causes of poor quality in -mj mode. (read that post of me referring to 192JS of the Velvet track) --- What I'm suggesting: a "-mx" mode (or whatever letter) it would be a JS mode, but unlike the "-mj" mode it would not try to predict anything, but just achieve optimal quality in an empirical way. --- for cbr: encode each set of samples to both a M/S and a S frame and take the one with least amount of introduced distortion. (can you use the calculation that now is used in vbr?) for vbr: see how low you can go in M/S, and then check if at this bitrate if S gives equal or better results. If so see how low you can go in S... --- I'd be slow, but it'd be the best possible quality for cbr and best quality/size for vbr. (as far as I can see) The advantages would be noticable: - low bitrate cbr mp3's (128kb/s,...) could harvest the full M/S potential and get extra bits where possible and would (theorethically) never sound worse (in distortion) than their S peer. If a M/S frame comes out sounding worse than S, the latter would be chosen. - vbr files would become smaller for the same quality as they are today, and I think that for higher -V* the quality effects would also be very noticable. I realise there will probably be complications if it's practically realised, but I think the idea behind it is ok. Any comments or action welcome :)) thanks -- Best regards, Roel/r3mix.netmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] can Lame Joint Stereo be "improved"?
Hello Mathew, Monday, August 21, 2000, 11:38:55 AM, you wrote: MH> Which version of the QDesign coder is this? With the last version of MVP I MH> tried, "fast" and "high quality" modes produced identical output for both MH> MP2 and MP3. MVP 2.5*. All verified by David McIntosh (employee of QD), so it's accurate. I had 4 different outputs for mp2/mp3/fast/hq sorry for the late reply, but I just received the list-messages. (3 days post-dato (?)). i think the mp3-mailinglist is seriously clogged... -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] can Lame Joint Stereo be "improved"? [re-send]
Hello, I don't know if any, and if, how much JS (something like the choice between MS or S) can be tweaked. Take this for example: http://r3mix.50g.com/velvet.zip (1900kB) I was doing testing for Qdesign, and this was the conclusion: > 1) FHG hq 192S : terrible, high squeeks in R channel > 2) Lame 192 JS : terrible, sounds like someone is shaking such a wooden > instrument filled with sand. less annoying than 1. > 3) QD mp2 fast : terrible, where did the frog come from ?? > 4) QD mp3 HQ : total mutilation, yeah! spacey effects, this is the worst around. >I think would sound like this when a robot has sex. > 5) QD mp2 HQ : low pounding distortion, L channel in start > 6) QD mp3 fast : L channel is lost: sounds like there is an extra > instrument introduced. Or maybe it has been through a WMA filter > or so. complete hollow sound. > 7) xing S hfreq: starting to sound like the original. however >constant noise, and I get a sea-sick sensation. hurts my head to >listen. > 8) xing S 16khz cutoff: give me a $2 pair of computer speakers and I >cannot distinguish this one from the original. > 9) mystery signal: ok, besides those 2 thumps around 5.5-6 seconds on >normal stereo > 10) Lame 192S : this sounds ok. probably not perfect, but my head > hurts from that xing sample. I can enjoy this one. So it's a hard to encode piece. * "LAME -ms -b192 -h" sounds ok * "LAME -mj -b192 -h" sounds certainly NOT ok wouldn't this be a nice clip to tweak the JS a great length? If lame would manage to get all that noise out of the R channel in JS, by making better decisions when to go to and from MS it would be a leap forward. This also offers the VBR (old/new) a big potential gain in quality imho. (Since audio glitches I encountered in vbr-new, ns-psytune and others, are mostly JS related.) btw: the piece is extremely hard to encode. It wouldn't be abnormal to have almost only S frames in JS mode I think.(?) I hope someone picks up on this :) thanks for listening [sorry for the re-send, but after 2.5 hours the original post still isn't on the list, so I assume it got lost somewhere...] -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] can Lame Joint Stereo be "improved"?
Hello, I don't know if any, and if, how much JS (something like the choice between MS or S) can be tweaked. Take this for example: http://r3mix.50g.com/velvet.zip (1900kB) I was doing testing for Qdesign, and this was the conclusion: > 1) FHG hq 192S : terrible, high squeeks in R channel > 2) Lame 192 JS : terrible, sounds like someone is shaking such a wooden > instrument filled with sand. less annoying than 1. > 3) QD mp2 fast : terrible, where did the frog come from ?? > 4) QD mp3 HQ : total mutilation, yeah! spacey effects, this is the worst around. >I think would sound like this when a robot has sex. > 5) QD mp2 HQ : low pounding distortion, L channel in start > 6) QD mp3 fast : L channel is lost: sounds like there is an extra > instrument introduced. Or maybe it has been through a WMA filter > or so. complete hollow sound. > 7) xing S hfreq: starting to sound like the original. however >constant noise, and I get a sea-sick sensation. hurts my head to >listen. > 8) xing S 16khz cutoff: give me a $2 pair of computer speakers and I >cannot distinguish this one from the original. > 9) mystery signal: ok, besides those 2 thumps around 5.5-6 seconds on >normal stereo > 10) Lame 192S : this sounds ok. probably not perfect, but my head > hurts from that xing sample. I can enjoy this one. So it's a hard to encode piece. * "LAME -ms -b192 -h" sounds ok * "LAME -mj -b192 -h" sounds certainly NOT ok wouldn't this be a nice clip to tweak the JS a great length? If lame would manage to get all that noise out of the R channel in JS, by making better decisions when to go to and from MS it would be a leap forward. This also offers the VBR (old/new) a big potential gain in quality imho. btw: the piece is extremely hard to encode. It wouldn't be abnormal to have almost only S frames in JS mode I think.(?) I hope someone picks up on this :) thanks for listening -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] MPEG audio decoder compliance
Hello Rob, Friday, August 18, 2000, 4:07:52 AM, you wrote: >> RL> If you can point me to a specific implementation I can try to test it >> RL> directly. The only requirement I have is that the implementation support >> RL> some way of saving the decoded output to a file (e.g. WAV). >> >> Would be great: http://www.daansystems.com/coolplayer RL> I tested CoolPlayer and added it to the list of results: RL> http://www.mars.org/home/rob/proj/mpeg/compliance/ thanks, I'll have a look right now... RL> One thing to consider is that the compliance test data only sweeps frequencies RL> up to 10kHz, so unfortunately any bizarre behavior above this would not be RL> detected. did you know I am a person that cares about the 16-22kHz region? :) I'm thinking the "sharp edges" I hear in some songs situate themselves above the >10kHz region. It is a problem because I consider something sounding like that "artifacted", but when I listen to the wav on the same computer, it sounds much softer. That's why I concluded it sounded off. >> maybe to be sure you can capture the output with totalrecorder. This >> way you can also assure that the output is the same as the .wav >> writer. RL> What is totalrecorder? a real fine product. captures all audio sent to the soundcard digitally by pretending it is one. Can be used to record any of those protected and encrypted formats. I used this to do some wma tests. http://www.totalrecorder.com/ -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] MPEG audio decoder compliance
Hello Gabriel, Thursday, August 17, 2000, 5:59:46 PM, you wrote: >> RL> If you can point me to a specific implementation I can try to test it >> RL> directly. The only requirement I have is that the implementation GB> support some >> RL> way of saving the decoded output to a file (e.g. WAV). >> >> Would be great: http://www.daansystems.com/coolplayer >> GB> It's useless as this player uses Xaudio GB> Gabriel Bouvigne - France ?? The point was that the test says Xaudio is perfect, and I can clearly hear something is wrong. The link was provided to test if the xaudio test was ok, or the implementation in coolplayer is ok. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] MPEG audio decoder compliance
Hello Rob, Thursday, August 17, 2000, 12:54:08 AM, you wrote: RL> If you can point me to a specific implementation I can try to test it RL> directly. The only requirement I have is that the implementation support some RL> way of saving the decoded output to a file (e.g. WAV). Would be great: http://www.daansystems.com/coolplayer maybe to be sure you can capture the output with totalrecorder. This way you can also assure that the output is the same as the .wav writer. Thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MPEG audio decoder compliance
Hello Rob, Wednesday, August 16, 2000, 6:03:28 AM, you wrote: RL> I'd also appreciate feedback. Are the results easy to understand? Is there any RL> information that could be added to supplement the results? Are there any other RL> relevant links to related information? Xaudio 1.3.1 [x86] seems to do perfect. Also read this on another site. Sad thing is, I know a Xaudio decoder (win32), and when listening, you _clearly_ can hear the high tones are much too sharp. I guess there must be some other tests also to conduct. Maybe the win32 players differ from the decoder lib? I don't know, but I do know how it sounds... If I compare with lame --decode, I get a totally different sound, but according to the test they should be both ok. RL> Are there any decoders I missed that could be added? please check http://privatewww.essex.ac.uk/~djmrob/mp3decoders/intro.html David is out this week, but his site also touches the subject. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Lame as .acm-codec? (Gaby? Dmitry? Nathan?)
Hi, I don't know how hard it is to get lame converted to a win32 codec, but I think it would have it's uses. Any win32 people wanting to give it a shot? I first was recalcitrant to the idea, but this mail has shown me a different perspective (it's like the 10th I get of these): ZM> Hi, ZM> ZM> I just found your nice site. Looks like you're the one who finally convinced ZM> me of changing from FhG to LAME. ZM> ZM> I think this isn't mentioned in your FAQs: ZM> Do you know if anybody has already created a Windows .acm-codec from the ZM> LAME code? This would probably boost it's popularity. ZM> ZM> Best regards ZM> ZM> Lars-Detlef Hedde btw: recalcitrant was in my english dictionary, synonym of refractory :) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] no loss ?
Hello Cavallo, Thursday, August 10, 2000, 8:40:19 PM, you wrote: CdC> i found this on the net CdC> http://www.emagic.de/english/products/software/zap.html CdC> what do u think about? go for the best&free lossless audio compressor: http://www.monkeysaudio.com/ -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] you must include sourcecode when using GPL :(( ? (mpg123)
Hello Monty, Thursday, August 10, 2000, 9:48:27 AM, you wrote: >> The only reason that holds him back is that the GPL.txt says he should >> include his source code with the program. >> >> Is there anyone who actually cares about this? M> Yes, a *very big* yes. He will incur serious wrath from the open source M> community if he violates GPL. well, I respect him, and love his work. But that's why I came here and asked. >> Any precedents? I mean, the gig is probably off because he's not >> inclined to offer his sourcecode. Damn shame because this is/was the >> #1 win32 player for me :( ... (free, fast, 130kbyte zip, skins, ...) M> The GPL is intentionally viral in nature. Part of its political intent is to M> force more software to be Open. If you don't want to open the source, you M> can't coexist with the GPL. i don't like politics. if it weren't for that horribe "*mitr* K*t**nov" who shamelessly compiled lame, adding a tag line for his site there, and thereby violating the GPL, adding no source of his work to the distribution, I, and many others, would never have heard of "LAME". (50.000 hits nearing) terrible morally depraved man that is... [I love you man!] M> Precedents: I don't know if I can pull up any lawsuits that actually got M> filed, but I can name many examples of companies who have gotten a stern M> talking to. yes, companies. this is just one person, offering a free player to the win32 platform. net result is that development will stop a step early, his player won't improve more, and since he has no time to finish his own decoder engine. sad thing is also that he is now crippled by this restriction, and will honor the GPL, while those "companies" you speak of shamelessly harvest and earn on the back of others. big analogy with outlawing encryption (now in UK very actual). the normal everyday citizen loses his rights of privacy, while the criminals don't care and encrypt their sensitive data anyways. :( M> Monty thanks for the clarification are there precedents of an piece of GPL upgrading to LGPL? best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] you must include sourcecode when using GPL :(( ? (mpg123)
Hi, The author of CoolPlayer (free,win32) is considering to put in mpg123 instead of the xaudio decoder. http://www.daansystems.com/coolplayer/ The only reason that holds him back is that the GPL.txt says he should include his source code with the program. Is there anyone who actually cares about this? Any precedents? I mean, the gig is probably off because he's not inclined to offer his sourcecode. Damn shame because this is/was the #1 win32 player for me :( ... (free, fast, 130kbyte zip, skins, ...) thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Why no mp1/mp2 files with mpg123?
Hi, The author of CoolPlayer (win32) is considering to put in mpg123 instead of the xaudio decoder. http://www.daansystems.com/coolplayer/ Downside is that it does not decode L1 and L2? Why this restriction? thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] "--nspsytune" really sounds (more than a fair amount) worse :-((
Hello Robert, Monday, August 07, 2000, 6:47:16 PM, you wrote: >> In order to get the (much) higher --nspsytune filesizes down, I used >> "--athlower -21" (or -20->-23) to compensate. [seems to go negative >> :)] RH> I'm sorry to say, but in my opinion it is a really bad idea to lower the file RH> size with that --athlower switch, you are tweaking at the wrong place here. it was just to test, as mentioned, I did an extra test with the -V4 VS the old -V1, without the use of --athlower. The findings are the same. JS quality is not good at all. (in any case) >> Seems logical to me to compare quality of vbr files only if they have >> some comparable size. RH> Sloppy speaking, the idea of Naoki's psy tuning is to increase the filesize RH> where GPSYCHO currently seems to fail, on tunes like vbrtest.wav. so this produces files averaging > 270kbit/s (-V1 -q1), that sounds very poor and >230kbit/s average (-V4) sounding equally poor. While my older 220kbit/s V1 file sounded perfect? RH> My observation on a song from the artist formerly known as Prince: RH> - the old VBR code makes it at an average of 130 kbits with -V4, sounds OK RH> - turning on Naoki's psy tunings: it grew on 196 kbits, nearly 50% larger! I found it to do the same + introduce noise. RH> I haven't spent much time at his tunings, but I fear that it always says RH> the sound is tonal, even if it's more noise like. I spent a whole afternoon (7 hours) trying and not 1 file I tried sounds better in any way. - JS files -> suffer big Q losses - S files -> seem ok -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Re: "--nspsytune" really sounds (more than a fair amount) worse :-((
Hello, RV> finding: "--nspsytune" sounds _a lot_ worse than the normal psymodel. RV> The graphs show a lower overall distortion amplitude, but there is RV> this noise that I can even clearly hear upto V1 (didn't test V0). I triple-checked this. Remember those noise graphs I made (original-decoded signal)? The maximum amplitude of the noise is lower with --nspsytune [actually V1 is lower now than the 256S cbr, what means that the vbr is working imho], which is good of course, but the JS bug (I'm assuming) makes that the lower-level noise is extra annoying. If anyone wants I make some of these graphs and put them up, to illustrate the issue, just let me know. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] "--nspsytune" really sounds (more than a fair amount) worse :-((
Hello Mark, MT> Naoki's latest work makes a significant improvement to the psycho MT> acoustics, so you might want to try it with --nspsytune. MT> (scalefac_scale can still be enabled with -q1). Some of the stuff in MT> --nspsytune will make it into the default settings soon. MT> Mark [ALL using 3.86beta] I decided to tests these new psymodel-enhancements. I compare VBR files of equal size using the normal psy-model VS --nspsytune. In order to get the (much) higher --nspsytune filesizes down, I used "--athlower -21" (or -20->-23) to compensate. [seems to go negative :)] Seems logical to me to compare quality of vbr files only if they have some comparable size. I compared the normal psymodels VS: lame -V1 -q1 -mj -h --nspsytune --athlower -21 lame -v -q1 -mj -h --nspsytune --athlower -21 lame -V9 -q1 -mj -h --nspsytune --athlower -21 for 4 files. [making 16 files] Then I double-checked my findings by using "-V4 --nspsytune" VS "-V1", which gave about the same size, just to make sure the negative --athlower's triggered no bugs. finding: "--nspsytune" sounds _a lot_ worse than the normal psymodel. The graphs show a lower overall distortion amplitude, but there is this noise that I can even clearly hear upto V1 (didn't test V0). Also, I find most "-V9 -q1" encodings using the normal psy-model enjoyable and somewhat accurate. The --nspsytune flaws really surface using "-V9 -q1 --nspsytune --athlower -21". I think there is something wrong with "--nspsytune" and Joint Stereo. I tried some stereo VBR files, and these sound a lot better already(, being only 1kbit/s larger) btw: I'm not being conservative or anti-"everything but vbr-old+psy", and would rather have been here to report that --nspsytune sounds a lot better than the old one. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Re: 3.86a, bug with -h ?
Hello Mark, Sunday, August 06, 2000, 11:34:04 PM, you wrote: MT> I tend to agree with this, and I think we should disable MT> scalefac_scale for now (it can still be enabled with -q1 MT> for testing) after some re-consideration this seems wisest imo too. after some reports of -q1 producing poorer results with lower bitrates, best not too take too many chances. I think I'll keep on using it, because I cannot find one single clip where I hear -q1 -V1 -b128 perform poorer than -V1 -b128. (and there is a real size benefit) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] DC cancelation, Live MP3s without gaps
Hello Frank, Saturday, August 05, 2000, 1:11:36 PM, you wrote: FK> I have a set of WAV files without silence gaps. After converting to MP3 and reconverting to FK> WAV there are gaps (20...40 ms) between the files. How can I prevent this? http://albumid.cjb.net has exactly that in mind. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Voice encoding questions
Hello alex, abcc> I feel guilty using a list mainly devoted to an open source codec (LAME) to abcc> further the development of ClearBand's 'proprietary' codec. (Is a standards abcc> based codec implementation proprietary? We don't sell the codec - we sell a abcc> multicast system, mostly to ISPs and corporations, and the proprietary part abcc> is the multicast part. My superiors just didn't want to license FhG's abcc> source, I guess...) I don't know if that would help. If you look at http://www.mp3licensing.com , you would see it costs >$1M to bring any mp3 encoder on the market. FhG+Thomson have patents on mp3, not only their code. http://www.mp3licensing.com/royalty/swenc.html http://www.mp3licensing.com/royalty/broadcast.html >We do not charge royalties for mp3 streaming or mp3 broadcasting >(e.g. Internet Radio) until the end of the year 2000. Beyond this >date we anticipate to charge a small annual minimum and a percentage >of revenue. However, this model is not yet fully developed because we >cannot yet oversee where this new market is going. best inform your superiors to rip off Ogg Vorbis, which is not patented ;-) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] corrupt mp3 finder
Hello Francois, Friday, August 04, 2000, 1:22:51 AM, you wrote: FdT> I am looking for a program to check the integrity of mp3's. I know that Nero Burning Rom does some sort of check on mp3's before burning them, but I haven't been able to find a similar utility FdT> to check my MP3's without Nero. FdT> I thought someone out there should know something What kind of integrity check do you want? I have a quite fast and easy in the programs I wrote for http://albumid.cjb.net. Just jumps through all frames, from header to header all the way to the end. (it's some kind of test, but I believe when it runs through 18frames and all is byte-exact you have some reassurance) FdT> Thanx FdT> Francois -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] 3.86a, bug with -h ? [re-send]
Hello Stephan, >> SE> Yes! This is also my experience. Especially when the Wav-File contains a >> SE> lot of noise (such as copys from cassetes) SE> No! I realy mean 3.85 -q1. And it´s very audible. SE> I will give some samples, if anyone tells me where I can upload them. (never SE> done before) for everyone: Stephan uploaded the files to: http://r3mix.50g.com I listened, I also think to hear something (slightly, but not 100% sure) weird about the voices sometimes, but -32000Hz files, filled with noise and "Lame -q1 -d -m j -V 2 -B 192 --lowpass 12.0 Hobbit.wav Hobbit-q1.mp3" and "Lame -h -d -v -q1 jo3.wav jo3q1.wav" |56 - 3 - 1,8% |||64 - 11 - 6,7% 80 - 52 - 31,7% ||96 - 59 - 36,0% |112 - 28 - 17,1% ||128 - 5 - 3,0% |160 - 4 - 2,4% is not really what I would use to archive material. could you try adding "-b128" and listening how it sounds then? sounds ok to me now. It's just: -q1 is a bit more agressive, but with -b128 (-V1), I never have encountered a file that sounds poor. I like -q1 alot, but as MT said once @ lower bitrate there is a higher risk of problems, I just take the -b128 and never any problems. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] where to get the daily snapshots (sources)?
Hello, normally I got 'm from: ftp://cedric.vabo.cz/pub/linux/apps/lame/ but last few days the site was down for me, and today I find a 46 byte file. I also know of that overnight CVS archive, but I cannot do anything with that because it's filled with ",v" files. any other alternative locations? thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] 3.86a, bug with -h ?
Hello Stephan, Wednesday, August 02, 2000, 12:23:01 PM, you wrote: SE> No! I realy mean 3.85 -q1. And it´s very audible. SE> I will give some samples, if anyone tells me where I can upload them. (never SE> done before) thanks! would be nice. if you cannot find a place to upload them/email to, just email me, and I'll give you name/pwd. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] 3.86a, bug with -h ?
Hello Stephan, Wednesday, August 02, 2000, 1:06:26 AM, you wrote: >> In 3.86a it seems, that this feature is always switched on. >> I'am using: >> -mj --vbr-old -V1 -b128 -F >> Adding -h has no influence. >> With the older 3.85, >> -mj -V1 -b128 -F >> gives better results as >> -mj -V1 -b128 -F -q1. SE> Yes! This is also my experience. Especially when the Wav-File contains a SE> lot of noise (such as copys from cassetes) that 3.85 sounds worse with -q1? Or do you mean 3.86? The quality gap between 3.85 and 3.86 is VERY big. They have nothing to do with -q1 though (scalefac_scale). I consider 3.85 -q1 -V1 transparent, but I would not recommend the current -V0 even as an option with 3.86. There are too many unresolved issues. Read the threads I posted a while back about vbr_mt and vbr_rh. the 386 vbr's are filled with noise, and the overall noise levels are much higher than 3.85. most of this is due to that >20kHz fault I described. try lowpassing the music (16k or so), just for the fun of it and listen again with 3.86. Should be a great improvement already. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] why does CD use 75 frames/s?
Hello Alberto, Monday, July 31, 2000, 8:56:53 PM, you wrote: >> Now I thought I'd seen it all, it comes to my attention cue files, so >> I assume also CD's, use a 'frame' as base unit, being 1/75 s. Anyone >> heard of this, or did everyone mistook the xx:yy:zz for >> min:sec:sec/100? AG> xx:yy:zz AG> zz are sectors. A sector in CDDA mode can store 2352 bytes, and AG> when you write CDs you have to write full sectors, that's why you have to AG> pad the audio data with zeroes when burning wavs obtained from mp3s. AG> So: AG> 44100*2*2 = 176400 bytes/second of audio AG> 176400/2352 = 75 blocks/sencond. WOW. So much common knowledge I didn't know about. Thanks alot :) Yeah, my eye fell upon this when I wrote some tools (albumheader.cjb.net) for the Album-iD. I used musiCutter for helping me, and after 1 day it came to me that not I but musicutter was inaccurate. (never imagined that :)) anyways, got my specs updated, and the AiD is ripe for support. thanks for the prompt reply -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] why does CD use 75 frames/s?
Hello, Now I thought I'd seen it all, it comes to my attention cue files, so I assume also CD's, use a 'frame' as base unit, being 1/75 s. Anyone heard of this, or did everyone mistook the xx:yy:zz for min:sec:sec/100? musiCutter is wrong in this, but I assume most programs are? Why is there such a thing? and what does 1/75 has to do with 44100? thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] could someone please make "lame --decode" AiD aware?
Hi,
The Album-iD specs are somewhat finished, and I wrote a program to
generate AiD's and stick them in front of mp3's. (all+sources at
http://albumheader.cjb.net)
All seems to work as planned, even LAME decodes the AiD-mp3 without
problems at first sight:
RV> "Club System - Volume 16.mp3" already has a valid Album-iD with length 3764
RV>
RV> E:\test>>lame --decode "Club System - Volume 16.mp3"
RV> input:Club System - Volume 16.mp3 44.1kHz MPEG1 2 channel LayerIII
RV> output: Club System - Volume 16.mp3.wav (wav format)
RV> skipping initial 1104 samples (encoder + decoder delay)
RV> Frame# 3764 [ 183178] 160kbs
problem: I don't know how lame knows where to start decoding, but I have the
idea that if, by accident, the AiD should contain a certain string,
lame could start decoding halfway the header or so?
To avoid this, could someone please add a piece of (C preferrably :))
code like this:
RV> const header= 'AiD'+ #01;
RV>
RV> function checkaid (filenaam: string): word;
RV> var i, numread: word;
RV> s: array [1..6] of char;
RV> h: string [6];
RV> f: file;
RV>
RV> begin
RV> assign (f, filenaam);
RV> reset (f);
RV> seek (f, 0); {jump to fist byte in "filenaam"}
RV> blockread (f, s, 1, numread);
RV> h:= header;
RV> if ( (numread= 1) and (s [1] = h [1] ) and (s [2] = h [2] ) and (s [3] = h [3] )
and (s [4] = h [4] ) ) then
RV> begin
RV> i:= Ord (s [5] );
RV> inc (i, Ord (s [6] ) * 256);
RV> checkaid:= i; {return the length of AiD}
RV> end
RV> else checkaid:= 0; {no Album-iD found}
RV> close (f);
RV> end;
to lame(CVS)? (excuse the pascal, but it's all I know)
"checkaid(mp3filename)" would return (0)d if no file found and
(the real startaddress)d if and AiD is there.
It'd be great to have "lame --decode" say "Album-iD found" if one is
there. (that place could be used in future to call an AiD->CUE function)
many thanks!
--
Best regards,
Roel mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] relation #samples, ms, frames ??
Hello, could anyone please tell me (where to find info) about the relation between #samples (in the wav), ms (milliseconds) and #mp3frames (how long is each frame exact? (short,long?)) I'm thinking on updating the spec (http://albumheader.cjb.net/) of the 'AiD'. btw: how do you people think about a non-mp3-frame-compatible tag (like ID3) VS Xing (is mp3 frame)? thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] about overlapping mp3 frames
Hello, I believe Robert said that mp3 frames overlap 50%, then would it be sufficient to init some values using _only_ the previous frame in order to play the next ok? So: I want good playback, starting with frame N, would it suffice to load up frame N-1, and then start playing @ frame N? (or do I need more frames (N-2, ...)) (I'm wondering to which frame to refer in the albumheader) thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] opensource C developer wanted for AlbumHeader for mp3
Hello, In one last futile attempt to get mp3 enhanced & completed, I set up a page. It's all I can do for "the cause", so if you're a C programmer, please visit: http://albumheader.cjb.net and get quick facts. Instead of keeping the thread in mp3encoder, I decided to delocalise 'project' so that if there's any intrest, polution would be kept out of this list. thanks for the time :) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Re: Severe bug in lame (when using -k)
Hello Mark, MT> I would guess it was introduced in 3.85: it requires a combination of MT> scalefac_scale (defaulted in 3.85, before that enabled with -Y ), and MT> not using enough low pass filtering for the amount of compression. If I believe the history log and my own tests, scalefac_scale was only defaulted since 3.86a and not yet in 3.85. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Site or organisation for the advancement of MP3?
Hello David, Tuesday, July 25, 2000, 4:25:35 PM, you wrote: DB> Don't forget about Vorbis ( www.vorbis.com and www.vorbis.org ) DB> David Balazic :), thanks for that shameless plug :) If there's a section on possible successors, I'll mention ogg vorbis. You know I tested the codec and found it far inferior to the current mp3 alternative, so I won't go along in the open-source hype. I also think that even if vorbis managed to get to the level of mp3 on side of support (hard and softplayers) and quality (or supercede for that matter), it will be slapped down by some ridiculous patent or lawsuit anyways. I know they don't use patented material, but chronical naivite deficiency is a condition I suffer... but indeed, I need to know if there are sites that promote mp3 like the vorbis people do with their format. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Site or organisation for the advancement of MP3?
Hello, A reporter I know is planning on writing a book about mp3. (benelux) We all know the downsides of SDMI and consorts, so I was wondering, is there a site or so that has a nice presentation and arguments why to choose MP3 above other formats? (that lists benefits to artists, consumers, privacy, maybe links to working mp3 initiatives) I'm trying to save myself a lot of time, and it would be nice to have some fresh information and facts. thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] vbr audio degredation
Hello andrew, Tuesday, July 25, 2000, 12:19:20 AM, you wrote: ac> When decoding mp3s to .wav (1) and using Cool Edit's Spectral View (2), to my ac> surprise I've noticed an obvious treble cut beyond 16KHz on VBR mp3s (3) I've ac> encoded with LAME. Is this intentional? How many different music pieces did you test to conclude that? I know some have an average cut>16kHz, but there are reasons for this. ac> Fortunately CBR mp3s (4) do not appear to suffer the same audio degredation. There is no audio degradation here imho ac> See http://homepages.ihug.com.au/~ozzmosis/lame-tests/ for an example. ac> Notes: ac> (1) Winamp 2.64 was used to decode to .wav. best use "lame --decode", as it's the only correct decoder around (check that decoding site) (but it makes no difference here) ac> (2) Cool Edit's Frequency Analysis (Alt+Z) can also be used to demonstrate ac> this, but remember to select the entire waveform Ctrl+A beforehand. ac> (3) VBR mp3s were made using LAME 3.85 with "lame -V1 -b128 -h -k -mj -q1" ac> options. verified ac> (4) CBR mp3s were made using LAME 3.85 with "-b224 -h -k -mj -q1" options. verified What happens imho, is that in the last few seconds you have a high freq and a low freq signal (the low voice). Whenever the low voice pops up in the song, the high freq (>16kHz) drops to the bottom of the graph. (leave the freq analysis window open and then press play to see this) My best guess is that the low freq signal simply masks the >16kHz tones when it occurs. This is quite often, -> average dB's of >16kHz drop in a ctrl-a graph. This is normal because in VBR mode the psycho-accoustic model determines which tones are masked by which, and at the times that heavy voice comes through, all high tones are masked => left out in the vbr mp3. I cannot hear a difference, nor some sort of artifacts. I think there is no problem, and the psycho-accoustics work fine. Roel/r3mix -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Off-topic: Portable CD Player
Hello Steve, Sunday, July 23, 2000, 8:16:52 PM, you wrote: SS> I'd really like to know what you found out though... I mailed this to Zia: There's loads of info on this topic here: http://bboard.mp3.com/cgi-bin/mp3/ubb/forumdisplay.cgi?action=topics&forum=Portable+MP3+Players&number=55&DaysPrune=30&SUBMIT=Go I think that if you wait a few more months for the RCA player, you've got one with multi-line display that shows names instead of numbers for tracks. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame 3.85 with --vbr-new -V 1 "hangs" (maybe old news)
Hello Johan, Sunday, July 23, 2000, 12:55:48 PM, you wrote: JA> When i try to encode the track "Kort Introduktion till Nada Yoga" from JA> the "Jag gör vad som helst för lite solsken" by Fläskkvartetten (swedish JA> band) lame hangs, it begins to encode the track but it does'nt get JA> anywhere it just consumes a lot of cpu. I isolated the problem to the JA> first 150kb of the file, i could mail it to anyone who's interested. JA> What i did: JA> lame385 -d --vbr-new -V 1 -h -m j song song.mp3 download the newest 3.86 alpha from dkutsanov's site: http://www.chat.ru/~dkutsanov/~index.htm Robert Hegemann fixed an endless loop bug and I'm thinking it's the same you're mentioning. 3.86 has "--vbr-new" defaulted. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] "clips": severe Lame click/clipping and showing odd behaviour
Hello Robert, Thursday, July 20, 2000, 12:59:20 AM, you wrote: RH> Hi Roel! >> Hello, >> >> With some small manipulations I managed to get a 750kB (music >> fragments) file together where Lame 386 vbr clips seriously. >> >> Please download zip#2 from http://r3mix.50g.com [100mb fast webspace, >> but no direct links allowed :(] RH> OK, did it.. great! thanks for all the debugging. I downloaded the newest *.br2 on that site. RH> I just fixed that problem with that *pseudo endless loop* :-) RH> It may have solved the problems with these clips too. RH> If you like to confirm this... I got a version vbrquantize.c edited 1:19am, if that's the one, I think I found another possible cause. I'll test it later this day when I can access CVS. (these outages are something in DNS?) thanks for all great work. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] I solved (another part of) the vbr_mt clipping&C1 prob (!) :-)
Hi, "solved" might be a an overstatement [:)], since the code still needs tweaking, but lets say I think I located a pain-point _very_ precisely... In short: something goes terribly wrong with >20kHz signals. to illustrate: http://users.belgacom.net/gc247244/extra/ns-386a-funny.png [wav: http://users.belgacom.net/gc247244/extra/ns.zip (500K) ] as you can see on the "newsweep" signal, vbr_mt actually outperforms vbr_rh on just about the whole spectrum _but_ messes terribly up on the >21kHz range. (strange discrete ath/sfb-jumps btw (?)) I verified my >20kHz assumption by cutting off (@19kHz) the "velvet" signal ,which gives much problems, and behold: the vast majority of the anomalies (C1 problem=gone) were fixed! [FACT ENDS HERE] [Welcome to my fairy fantasy land] I'm going for an educated guess: * 22 (0-21) sfb's, each with start and end ath's * I actually made a visualisation of the ATH's: FFT([320-vbr](sweep)) * Ideally it would be smooth (like vbr_mt reaches by empirics) * so all Area between smooth graph and "saw-tooth" graph symbolizes an avg non-optimal (too large) frame-size choice * ath(sfb(21.end)) is terribly wrong, and could eg. be better =ath(sfb(21.start)), which would quickly fix bug * trying to get that saw-tooth smoothened would be a more fundamental fix? [Scholar, how much out of 5 did I get? Rate the eternal student please.] -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] "clips": severe Lame click/clipping and showing odd behaviour
Hello Robert, Thursday, July 20, 2000, 12:59:20 AM, you wrote: RH> I just fixed that problem with that *pseudo endless loop* :-) Yes, just tested, and works like a charm... RH> It may have solved the problems with these clips too. RH> If you like to confirm this... I think about 50% of all distortion is out! Distortion peaks much lower now and some clips gone. I hope you have some useful info on what I found about >20kHz, and maybe the other 50% is gone :)) thanks! -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Re: zip#2
Hello Mark, Wednesday, July 19, 2000, 5:14:31 PM, you wrote: MS> The site is dead for me also ... 768K DSL from Ohio USA. Murphy's law has MS> been strong this year. MS> mark stephens yes it seems. thanks for letting me know. So, this afternoon both sites are down. (1st time in 4 months) anyways: http://users.belgacom.net/gc247244/extra/clips.png is reachable again So I moved the lot to backup server #3: and the Test Signal site is moved over to http://home-4.worldonline.be/~ir003570/ so the wav is at http://home-4.worldonline.be/~ir003570/clips.zip sorry to all for the inconvenience. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] "clips": severe Lame click/clipping and showing odd behaviour
Hello Robert, RH> Hi Roel! RH> Sorry, but I can't reach that site! hmm, seems the belgacom.net server is down. The pic is also in the zipfile I mentioned. Sorry for that... "Please download zip#2 from http://r3mix.50g.com [100mb fast webspace, but no direct links allowed :(]" -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] "clips": severe Lame click/clipping and showing odd behaviour
Hello Robert, Wednesday, July 19, 2000, 2:16:28 PM, you wrote: >> Please download zip#2 from http://r3mix.50g.com [100mb fast webspace, >> but no direct links allowed :(] RH> Sorry, but I can't reach that site! help, murphy or just typical. never had any problems, but maybe your "lynx" and the site don't agree :)? try http://r3mix.50g.com/clips.zip, but if possible just http://r3mix.50g.com because I don't want to be kicked. Strange, because even my opera works, and all Javascript and Java are disabled for me... let me know, otherwise I'll just add to r3mix.net, but I'm running outta webspace there :( >> visual aid/necessity: >> http://users.belgacom.net/gc247244/extra/clips.png >> >> "odd behaviour": Lame 386 V1 took _2 MINUTES_ on this 8 seconds clip, >> where 385 only takes 3 seconds. First I thought "endless loop >> initiated", but apparently not ... RH> I would like to try it, but see above... just tested, and site is up? RH> Just to be sure, did you decode the MP3s with LAME? "lame --decode" thanks for the interest. I was thinking I was in some kill-files by now. :) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] "clips": severe Lame click/clipping and showing odd behaviour
Hello, With some small manipulations I managed to get a 750kB (music fragments) file together where Lame 386 vbr clips seriously. Please download zip#2 from http://r3mix.50g.com [100mb fast webspace, but no direct links allowed :(] visual aid/necessity: http://users.belgacom.net/gc247244/extra/clips.png "odd behaviour": Lame 386 V1 took _2 MINUTES_ on this 8 seconds clip, where 385 only takes 3 seconds. First I thought "endless loop initiated", but apparently not ... for the ones wondering: that's all for now and the next few days/weeks (relief :)) btw: I notice that the noise levels of vbr_mt are substantially higher than vbr_rh, even though the files are bigger. Why is this? ($1MQ) suggestion: if all tweaking effords should fail, would it be feasible to switch back to vbr_rh search _for some frames_ while conditions are extreme? -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] 386 vbr much more sensitive to peaks/clips
Hello, I just tested a 70 minutes live concert, and while lame385 V1mj gave me 1 clip total average 178kbit/s, lame 386 V1mj gave me about 15-20 clips and 200kbit/s average. I tried to get >10 clips in 1 wav, but then I get a vbr avg-ing 256kbit, and almost no more clips. So the clips in http://users.belgacom.net/gc247244/extra/velvet.zip http://users.belgacom.net/gc247244/extra/320S-V1-JS-vbr_mt.png were no coincidence :( -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] fast & easy finding of VBR encoding bitrate misjudgements
Hello, I believe the main problem with VBR encoding was that it sometimes mis-assesses some information, and takes a too low bitrate resulting in artifacts? I was just thinking. (always at wrong times) With the help of a (very quick) test like http://users.belgacom.net/gc247244/extra/320S-V1-JS-vbr_mt.png the worse faults would be easily identifiable? Why not encode, for example, a 2 hour music piece in * 320, Stereo * V1 - JS (or alike) then decode both back to wav, and inverted mix paste both. Now only rests to evaluate the highest peaks (aberations from good encoding), and try to minimise them by tweaking the VBR engine. [the hard part that is] It wouldn't help for all (eg "C1"), but I think it could be a very handy aid in finding the worse errors? -- Best regards, Roel mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Some more graphical comparisons: vbr_mt VS vbr_rh
Hello , Sound Clip: (1900kb) http://users.belgacom.net/gc247244/extra/velvet.zip What I did to find apparent differences: I encoded 1 file 320S and decoded (to get delays etc right) Then I did an inverted mix paste of the V1 vbr_rh and V1 vbr_mt, so that the differences would be highlighted. 320S-V1_vbr_rh http://users.belgacom.net/gc247244/extra/320S-V1-JS-vbr_rh.png 320S-V1_vbr_mt http://users.belgacom.net/gc247244/extra/320S-V1-JS-vbr_mt.png in "C1" notice one example of that "velvet" noise I was speaking earlier about. in "C2" I there are 2 clips. maybe also worth looking into? I was wondering, is this kind of analysis useful? (easy, much more objective than listening tests) -- Best regards, Roel mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] A clip that chokes vbr_mt, but not vbr_rh -> More Info ...
Hello Mark, I put it (temp) on my website: (1.900kbyte) http://users.belgacom.net/gc247244/extra/velvet.zip Ok, I found some _visual_ confirmation of the noise component I keep hearing in the R channel. This is there with vbr_mt, but not with vbr_rh. I used 385: "lame -V1 -mj -h -q1" I used 386: "lame -V1 -mj -h" with newest CVS version (dbQ and scalefac_scale default), thanks Robert :)) In the right channel 5.492s to 5.496s there is a distortion PEAK: 5.85: Mono Min Sample Value: -608 Max Sample Value: 502 Peak Amplitude: -34.24 dB Possibly Clipped: 0 DC Offset: -.086 Minimum RMS Power: -47.79 dB Maximum RMS Power: -36.56 dB Average RMS Power: -42.24 dB Total RMS Power:-41.21 dB Using RMS Window of .01 ms 3.86: Mono Min Sample Value: -1686 Max Sample Value: 1672 Peak Amplitude: -25.68 dB Possibly Clipped: 0 DC Offset: -.052 Minimum RMS Power: -45.08 dB Maximum RMS Power: -26.36 dB Average RMS Power: -33.2 dB Total RMS Power:-31.9 dB Using RMS Window of .01 ms As you see, this is a 10dB difference, and I think I can hear it. Also looks nasty on gfx. I'm guessing it's some JS masking thing because this is at the hight of a peak on the L channel? Hope this info is useful. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Anyone wants to update CVS with new dbQ[]?
Hello,
after a lot of testing, I came to something like this in
vbrquantize.c
dbQ[10]={-6.06,-4.4,-2.9,-1.57, -0.4, 0.61, 1.45, 2.13, 2.65, 3.0};
_combined_ with "-q1" this should (for average files)
get -V9,-V4,-V1 back to the size it was with vbr_rh, all the other
values interpolated inbetween.
Anyone has objections, reasons not to do this? (and also default to -q1)
I thought I'd put it forward because the current "0.75" for V9 (and
everything >V4 )is _by far_ too large, so I thought a re-scaling could
help settle the vbr bitrates as they were established in <=3.85?
--
Best regards,
Roelmailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Great mp3 decoder test site (check lame results)
Hello, If you haven't already, you should check out this decoder test page... http://privatewww.essex.ac.uk/~djmrob/mp3decoders/intro.html All tested, and on "objective sound quality" there is one more thing to do :)) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] 32 or 44.1kHz for 128 kbit/sec mp3s fromsoundcard?
Hello Naoki, Thursday, July 13, 2000, 9:10:08 AM, you wrote: Jaroslav>> Sure. But not only metal. All music needs bandwidtw up to 100kHz. Ears Jaroslav>> cannot hear stable sinus frequency, but music is not sinus; music is Jaroslav>> impulses, that have more energy at band >20kHz, and you can hear it all (by Jaroslav>> not by ears and only impulses, not sinus). NS> Here are results of interesting experiments about this issue. NS> http://www.etl.go.jp/%7Eacoustic/research/hf-e.html "Several recent researches, however, had argued about subjective difference between sounds sampled at 44.1kHz and 96kHz. What can make inaudible ultrasounds audible is not known." and then tested on 4 students. It's like, if man can hear presumably 20Hz->20kHz, why do I sense being hit by a hammer 2x each second? It's only 2Hz! I have my doubts, but I think current mastering engineers should put a bit more efford in trying to fill the <21kHz spectrum and keep the recordings as clean as possible. In my everlasting seach for artifacts, the most inperfections I find are there right in the source material. (poor samples, bg noise, clipping, overamplified distorted audio). I see not much practical use in 95kHz sample rates, and percieve it only as a means to get a new copy-protected & patent-crippled medium on the market. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] a suggestion for dbQ[10]= ...
Hello,
Tuesday, July 11, 2000, 6:25:46 AM, you wrote:
MT> If you want to try further adjusting the tunings
MT> the real thing you want to play with is the dbQ[] array
MT> in vbrquantize.c:
MT> static const FLOAT8 dbQ[10]=
MT>{-5.5,-4.25,-3.0,-2.50, -1.75, -.75, -.5, -.25, .25, .75};
I've been working on this. Problem is that
- or I loose bitrate on hard pieces (*)
- or I set the hard to encode, and get an overal avg size increase
for the moment, I'd suggest (*)
static const FLOAT8 dbQ[10]={-4.76,-3.9,-3.04,-2.175, -1.31, -0.45, 0.41, 1.28,
2.14, 3.0};
AND
-q1 defaulted (**)
I benched the filesize of 3.85 V1&V9 to match 3.86 V1&V9 using an
averagely difficult piece to encode. V1&V9 are the most important in
the scale (to me), because V1 stands for transparent-vbr and V9 as
smallest avg defined in old vbr(, for the people needing it.)
Then, I simply did a linear interpolation between these. I see no
need to make the gap between V1 and V2 greater than the one between V8
and V9.
(**) I used "Lame -V(1/9) -mj -h -q1" [3.86] to compare to "Lame
-V(1/9) -mj -h" [3.85] because that way the better(***) -q1 can be
used without the risk of a too low bitrate on -V9 -> -V3.
(***) -q1 was just a more extensive search algo to find lowest
possible bitrate to fit quality I think?
(*) The average pieces should somewhat match, but the hard to encode
ones will be under-dealth bits in current state compared to their 3.85
processing. I hope this can be compensated by, for example,
- making the JS mode more picky on when to go for MS because this
happens too often right now (see 'velvet-bug') => larger filesize
{- maybe making the highest sfb's have more importance (? higher
abs(ath)) so that the chance of high freq distortion (which is about
the only important one left at this bitrate imho, besides MS stereo prob)
is lowered significantly? =>larger filesize} (could be totally wrong
comprehension of the psy-coding-thingy, if so, please ingnore :))
I know I'm assuming a lot (lack of knowledge), but I hope my
blabberings are somewhat constructive and useful.
--
Best regards,
Roelmailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Full Huffman Search
Hello Chris, Tuesday, July 11, 2000, 11:37:35 PM, you wrote: CH> We know that LAME now has roughly the same quality of MP3Enc 3.1. But, CH> as far as I am concerned, full huffman search hasn't been implemented CH> on LAME yet. I've noticed LAME 3.8x produces better quality than 3.70, CH> and I presume the main reason is the more efficient huffman coding of CH> Takehiro. MP3Enc does full huffman search on qualilty 9. So, should MP3Enc CH> with -qual 9 switch sound a bit better than LAME -h? Please let me know. MP3Enc flattens the sound and the >16kHz region is not at all coded accurately. Good for lower bitrates, a waste for higher (eg 256S) http://users.belgacom.net/gc247244/analysis.htm#MP3ENC31 is a test I did a while back. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] A few questions about LAME (such as -q1)
Hello David, Tuesday, July 11, 2000, 6:18:06 PM, you wrote: D> What is this -q1 parameter i've seen here on the list ? D> is it for VBR,ABR, or CBR ? D> is there -qx or only q1, tell me about it -q1 should be an optimalisation by Takehiro Tominaga running a more extensive search to find smallest framesize to fit a certain quality. Not (yet) standard because some reported it to artifact in lower bitrates. Maybe a good idea would be to 1- measure current non-q1 size of lower ranges 2- default -q1 at all settings and lower the ath tweaks a bit so this new size == older non-q1-size, giving better Q at equal size? D> And like i mentioned in another post, what's up with --vbr-old and --vbr-new D> ? D> since --vbr-old is the default and slowest i'm guessing there is something D> wrong with --vbr-new D> i'm using 3.85 and want the best quality i can get :) 256S, or V1-q1 if you care about space ( http://www.r3mix.net , subjective within boundaries) btw: I do listening tests, but this is so arbitrary I use gfx tests, where possible, to get my points across... -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] new VBR code
Hello Pierre, Tuesday, July 11, 2000, 2:41:54 PM, you wrote: PH> I've been told several times that at 192kbs or above, mp2 is likely to be better than mp3. True or False ? Goh, that's hard. I think reason for this is that many radio stations use professional mp2 solutions, which are tweaked to the limit. (try Qdesign) Compare this, 2 years back, to the only HQ FhG alternative, and the FhG mp3 gives you a muffled-sounding mp3@256 while some mp2 encoders give a crisp sound. Mp3 has everything in it to surpass mp2, but I see no reason, beside compatibility (not all mp3 players do mp2, even though backward compatibility), not to use mp2 @ 256 and up. 192 is insufficient in both MP3 and MP2. Advantage @192 is that mp3 can give you nice MS frames in JS mode, saving alot of Q, and MP2 is restricted to the poor-sounding IS modes leavind JS not really an MP2 archival option. PH> If true, would it be difficult to add a mp2 option in lame (I don't know to which extent mp3 and mp2 differ) ? PH> If no, isn't it the solution for top quality ? Lame delivers the crisp sound of xing without the artifacts, so I'd go for 256 mp3/Lame. Tried Blade now, and found the psy seriously hampered in the 1 clip I tested. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] The "-b128" bug in 386 again, now with example
Hello Robert, Tuesday, July 11, 2000, 4:44:49 PM, you wrote: RH> OK, once again, there is no -b128 bug!! The thing that confuses me is that with older versions of lame when -b128 specified, I got or 128k and above or 32k (analog silence) I never got anything inbetween. Now this all changed, I assumed a bug. RH> A typical stereo mp3 frame consists of two granules and 2 channels. RH> So you have to encode: RH> granule1 left-channel RH> granule1 right-channel RH> granule2 left-channel RH> granule2 right-channel RH> That makes 4 possibilities to detect analog silence. So analog silence is 4x checked? It's possible to get 1 frame with 1 AS and 3 non-AS granules? RH> These sections will be encoded with your selected quality RH> resulting in a need of XYZ bits all together. RH> Now it goes into packaging these already encoded granules RH> into a sufficient frame, a frame which provides enough bits. RH> If analog silence is detected, then all these 4 sections RH> will be packed into a frame of a lower bitrate then say 128kbits, RH> but only if XYZ bits will fit into it. RH> It could also be packed into a frame of a larger bitrate, but RH> that would make no difference in terms of quality, as these RH> granules are already encoded and use XYZ bits. RH> If you force (-F) LAME to use exactly a 128 kbits frame, RH> this could result in a huge waste of bits on long silent RH> passages. This is why MT introduced a over-riding of -b* in case of AS, to take only 32kb frames there. This feature seems lost now? RH> Roel, maybe it is time for you to get a version of LAME with RH> the frame analyzer MP3x included. You would need the GTK dlls RH> too. Then you can see what LAME does on every frame. RH> Robert RH> PS: RH> analog silence - there is some energy in every band, but RH> it is below the ATH RH> digital silence - there is no energy in every band Then, if this all has to make sense, the algorithm was refined from 3.85 to 3.86 so that the difference is * =<385 gave 32kbit/s frames on parts with AS on all 4 granules and 128 to all other with at least 1 granule non-AS? I'm sorry for the extreme stubbornness from me on this issue, but I still think there is a misunderstanding (on my behalf). I encoded countless albums and songs with lame VBR by now, and I _never_ got anything else than 32k and 128k and up. Now I get 112,48,40,96 frames on just about all albums. Only tells me something has changed, and I assumed this was a bug, but I never considered this was willingly. I am now living an existentiality crisis about the '-b' option. thanks for the lengthy explanation. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] The "-b128" bug in 386 again, now with example
Hello Robert, Tuesday, July 11, 2000, 4:44:49 PM, you wrote: RH> OK, once again, there is no -b128 bug!! My apologies. i don't/didn't understand. I'll read everything over again and try to comprehend why 3.85 and below functioned as I expected and 3.86 doesn't. thanks and sorry for the inconvenience. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] The "-b128" bug in 386 again, now with example
Hello, I know I keep going on about this one, but I am reasonably convinced something is wrong beside that "analog silence". 386 keeps giving me _consistently_ frames below 128k with "-b128" specified. I've been told this has to do with analog silence, but there is simply _no silence_ in next clip: http://users.belgacom.net/gc247244/extra/ns.zip (500K) I don't get it, if there is analog silence detected, the frame should be silent (who no 0-frame?), and encoded at 32k, not 96 or 112?? (unless overridden by "-F") This was the case in previous versions, and I don't understand why I keep getting these lower bitrate frames now. There simply is no use for -b128 if it is like this. At -V4 and higher this causes poor results in some encodings, so I think overall Q will improve if this is fixed. -- info: E:\r3mix.net\newsweep\386a>lr -V1 -mj -h -b128 ns.wav ns386a.mp3 LAME version 3.86 (alpha 1) (www.sulaco.org/mp3) Encoding ns.wav to ns386a.mp3 Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG1 LayerIII ( 6.0x estimated) qval=2 Frame | CPU/estimated | time/estimated | play/CPU | ETA 383/ 383(100%)| 0:00:10/ 0:00:10| 0:00:10/ 0:00:10|0.9584| 0:00:00 - bitrate statistics - [kbps] frames 32 0 (0.0%) 40 0 (0.0%) 48 0 (0.0%) 56 0 (0.0%) 64 0 (0.0%) 80 0 (0.0%) 9611 (2.9%) 11228 (7.3%) 12837 (9.6%) 160 103 (26.8%) 192 157 (40.9%) 22448 (12.5%) 256 0 (0.0%) 320 0 (0.0%) average: 173 kbs E:\r3mix.net\newsweep\386a>lame -V1 -mj -h -b128 ns.wav ns385.mp3 LAME version 3.85 (www.sulaco.org/mp3) Win32 binaries from www.chat.ru/~dkutsanov/ Encoding ns.wav to ns385.mp3 Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG1 LayerIII ( 6.0x estimated) qval=2 Frame | CPU/estimated | time/estimated | play/CPU | ETA 383/ 383(100%)| 0:00:12/ 0:00:12| 0:00:12/ 0:00:12|0.8127| 0:00:00 - bitrate statistics - [kbps] frames 32 0 (0.0%) 40 0 (0.0%) 48 0 (0.0%) 56 0 (0.0%) 64 0 (0.0%) 80 0 (0.0%) 96 0 (0.0%) 112 0 (0.0%) 128 121 (31.5%) 160 214 (55.7%) 19249 (12.8%) 224 0 (0.0%) 256 0 (0.0%) 320 0 (0.0%) average: 154 kbs -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] new VBR code
Hello Steve, Monday, July 10, 2000, 11:27:36 PM, you wrote: >> As noted in the other post, I, and many with me have very little to >> complain about in with the <=3.85 vbr_rh mode... Cannot find any >> glitches since 3.83, encoded a few hundreth albums and counting... SS> So wait, I'm not quite understanding you. Are you saying I should stick SS> with 3.83, or are you saying I should upgrade to 3.85 for the best VBR mode SS> encoding? A visitor from my site found that -V1 on <=3.82 used too few bits on some clips (kingdom.zip), I verified. Iicrc Mark Taylor fixed this in 3.83, but the 3.83 gave relative big files compared to older versions. Then Takehiro Tominaga brought "-Z" (now -q1), that brought the size back down again, and kept the improvement. (at V1, because some say -q1 is too agressive at lower bitrates) I use 3.85 beta now. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Lame development matures ...
Hello, I was just listening to that 'obvious artifact-creator' that makes vbr_mt do strange things. Sad thing is that I cannot really easily detect it, on my stereo that is. I'm just guessing more people will find it hard to detect. It is however, very clearly present when I listen with my headphones on. At the risk of sounding even more arrogant, I'd like to advise everyone here, putting hours in the development of LAME, if they have not already have done so, to _invest in some decent pair of headphones_. I myself bought a good pair of Sennheiser HD-490 headphones ($45, belgium) and a sb128 soundcard ($25, nice linear play and high S/N ratio(linux compatible, ensoniq)). I think this would be a _very_ rational investment, considering the countless hours spent tweaking and perfecting lame. I've heard several times that people say: I cannot hear the artifacts because of my bad hearing (age), but I'm convinced that just about everyone here can hear what I'm hearing (with ease). _Take my word for it_ that when you listen to some clips with this $70 equipment you * will hear the >16kHz region (and miss it when filtered out) * will find 192 insufficient for some uses, let alone 128 It's just, being blunt (we're all adults), I find it such a loss of efford and time and unnecessary introduction of arbitrariness to the debate of sound quality when you don't explore this option. (btw: my hifi is _not_ a crap system, but the headphones just add a completely other dimension) -- Best regards from your very own little arrogant pusher, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] A clip that chokes vbr_mt and blade256S, but not vbr_rh
Hello Mark, Monday, July 10, 2000, 7:27:20 AM, you wrote: MT> yes, please send me the .wav files with a description of the MT> problem. I have two samples already with artificts, but I MT> haven't had a chance to figure out what is wrong. MT> Mark I put it (temp) on my website: (1.900kbyte) http://users.belgacom.net/gc247244/extra/velvet.zip lame385 (vbr_rh) sounds acceptable to me using: "-V1 -mj -h -b128 -q1" lame386a (vbr_mt) _is bigger_, but has artifacts in R channel using "-V1 -mj -h -b128" best to compare using "-V3 -k" or compile alpha with qadjust=-.5 and -q1 so that the filesize/&/lowpassfilter/&/ath's of sfb's are comparable to 3.85 setting... R channel .5 sec,1.5,2.35 sec etc ... has very annoying high tones in it using vbr_mt. I hope someone can find out what can be done to fix the problem... blade.93.6-2: also some problem like described with newer lame VBR + weird sounding bass-deformation around 6.5s. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] new VBR code
Hello Mark, Monday, July 10, 2000, 6:21:20 PM, you wrote: MT> The thing I worry about with VBR is the following: MT> A VBR with an average bitrate of 180kbs may sound as MT> good as a 200kbs CBR 99% of the time. But 1% of the time MT> the psycho acoustics could screw up and use 128kbs MT> when it needed 180kbs. So 1% of the file might only be MT> as good as a 128kbs encoding. So which is better: MT> 1: average bitrate 180kbs which sounds like 200kbs 99% of the time MT> and 128kbs 1% of the time. As noted in the other post, I, and many with me have very little to complain about in with the <=3.85 vbr_rh mode... Cannot find any glitches since 3.83, encoded a few hundreth albums and counting... MT> 2. CBR 180kbs which sounds like 180kbs 100% of the time On my HQ headphones I pick out many 192 mp3's. There are _a LOT_ more instances where 192 isn't enough and the -V1 picks out a good higher bitrate frame than an instance where VBR screws up. (vbr_mt that is) A few months ago a 192 was somewhat considered perfect for me, but when I upgraded hardware, it was not so hard to find flaws. If you want the best possible mp3's, just take 256cbr or 320. proven statistically to be of the same Q as original material. (ti: you can distinguish some test sounds, but 256 does not sound bad, as being the exception). VBR 256kbit/s average VS 256kbit/s cbr is another story. The chance of psy messing up in VBR is now much bigger than 256cbr being insufficient. MT> ??? I think it makes sense :) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] {qadjust=-2.5} to {qadjust=-.5 and "-q1"} ? (lame)
Hello Mark, I see not much reason to disturb the current (<=3.85) way things were scaled. (read down why) MT> The goal is something like this: MT>VBR_q compression like MT> 05.0 MT> 16.0 MT> 38.0 MT> So -V6 is supposed to give, on average, 128kbs. MT> -V0 is supposed to give, on average, 256kbs. This doesn't really MT> make sense because you might as well just use 256kbs CBR, but this MT> is because many people expect that -V0 should give the best possible MT> quality. -V1 should be around 220kbs, and with another 20% reduction MT> from jstereo, that is down to 180kbs. The V1 using your "qadjust" uses much higher bitrates in JS mode. I also aim at 170->210 kbit/s average with respectively easy and hard to encode music. I have one song that averages >280kbit/s with the new scale. There is no real funded reason to get vbr averages this high I think. * >210kbit/s averages you should opt for 256kbit/s cbr, because the chances are then much higher to get better quality. Vbr (archival quality) only makes sense, imo, around 185kbit/s average. Easy pieces will go as low as 160 and very hard peak at 220. The reason for this (refering to your Q/remark in the other post) is that a simple 192kbit/s is simply _not_ good enough for archiving. If you play those on a good soundcard+ HQ headphones or hifi you will pick most music out. It is more than necesary sometimes for some frames to go up to 256 and even 320, and if you choose 192, your music quality constantly is not good enough. offering people a vbr mode >=256 is giving them the illusion this Q will surpass 256cbr imho, and not much use for that I think. * I also find it non-logical to not-adapt the lowpass filter to the new scale (if this makes it as default). I find it quite ridiculous that with '-V3' on qadjust=-2.5 I get averages up to 229kbit/s on my music, but the frequency is cut off? who has use for this? imho, anyone willing to go for averages bitrates >200kbit/s wants _perfect_ (* ... you know) music, and a lowpass filter on -V3 is quite silly. if someone chooses to accept files > 200kbit/s (hard to encode), they expect full range audio, and no filters. The old -V1 had this right. The new scale forces me to take -V3 (in order to produce some responsible size), defaulting a lowpass filter. [I am aware I can disable the filter, but the underlying argument is the issue, not the fact I can hack some reasonable result out of it] * I, and many with me (these are the people that are willing to use VBR) did many vbr listening tests, and are very content with the old scale. I think there is not much reason to change the scale in the drastical manner it happened with 3.86alpha. I encourage, and would like to see it tweaked, the new vbr_mt, because of the great speed advantage in vbr mode. MT> All the various default settings (jstereo, lowpass filtering) are MT> based on the compression ratio. For VBR, the compression ratio is not MT> known in advance, so LAME uses the above table. In short: Don't fix what isn't broken. On my site (>3 hits right now) I have had only 3 people mailing me that they found some disturbing artifacts in the "LAME -V1 -mj -h -b128" mode[<=3.85]. Two of them were resolved with 3.83 (and 3.84-Z), and the one I cannot hear myself, but I had to suggest 256cbr to solve the issue. The old scale was ok imho, because I think there is not much foundation to advice people to use vbr's averaging >256kbit/s. You yourself have mentioned in the usage file that vbr is not advisable for HQ work because of possible PSY errors etc, so I find it very surprising to see the creation of the new scale. >> Negative: >> - some nasty artifacts in a file I encoded (every vbr_mt does >> worse than vbr_rh on this file), I'll address this in another >> thread. (*, if desired) MT> yes, please send me the .wav files with a description of the MT> problem. I have two samples already with artificts, but I MT> haven't had a chance to figure out what is wrong. I'm looking into this later this evening... Roel, voting qadjust=.5 and -q1 for standard, so we can start finding artifacts without the use for "-k" in a decent filesize rate. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] new VBR code
Hello Mark, Sunday, July 09, 2000, 9:24:15 PM, you wrote: MT> I do all my testing at 128kbs and lower, and I still MT> feel that 128kbs CBR is on average better than VBR (128kbs average) MT> At higher bitrates, (see r3mix.net for example), there is MT> some evidence that VBR outperforms CBR. But this is mostly MT> based on signal processing tests - not hearing tests. hearing MT> tests are hard to perform at such high bitrates because MT> everything sounds pretty good, and I think the evidence MT> is not conclusive either way. I wrote on my site that the new VBR is best not used for archiving, because of the many bugs. I'm always up to some listening/tweaking tests etc, but no-one here seems to respond to some remarks. I wish I was able myself to change the code, but I admit this kind of brainwork is somewhat out of my leage at the moment. Anyone have a remark to that 'qadjust' variable issue? thanks MT> Mark MT> -- MT> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] {qadjust=-2.5} to {qadjust=-.5 and "-q1"} ? (lame)
Hello, I've been experimenting all day with the "vbr_mt" mode, because of the great speed advantage over "vbr_rh" in it's current form. No need to tell anyone the vbr_mt generates very large files, and I found -V3 (mt) to be somewhat the filesize-equivalent of -V1 (rh). What bothered me was the lowpass filter used by -V3, and after analysis knowing that "V1" should give better Q than "V3" (ATHs of sfbs are different anyhow, so I assume...) After 8-9 hours of trying to grasp a fraction of the source (no programmer, no psy-coding background, plain dumb :)) (in a futile attempt to find the reason why "-b" is misinterpreted (?)) this catched my eye: qadjust=-2.5; /* start with -1 db quality improvement over quantize.c VBR */ in Mark's vbrquantize.c. Why this "-2.5"? Anyways, I changed the thing to some other values and "qadjust=-.5;" combined with "-q1" gives filesizes/bitrate distributions very much like the --old-vbr. (meaning: V1,JS=transparent for most, at 170-180kbit/s average) Checked with "-V1 -mj -h -b128 -F -q1" (on loads of files) and extra is that -V4 files with -q1 give relatively bigger files now, so maybe q1 can be defaulted on vbr_mt? Positive: + now 3x faster VBR + compareable V0-V9 scale Negative: - some nasty artifacts in a file I encoded (every vbr_mt does worse than vbr_rh on this file), I'll address this in another thread. (*, if desired) - "-b128" still gives me 40,112 kbit frames. I thought "/* disable analog_silence if *any* of the granules != silence */" was sufficient to discriminate analog silence, but I am missing a point I think :( btw: are these kinds of comments useful? (*) and how about: I found some nasty artifact @vbr_mt/V1 (which should be transparent imho), but cannot fix myself...? . While going through the source-code, I felt what Pathfinder must have felt like on Mars (..., the third week after landing there) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] about the new LAME vbr
Hello, I just compiled the newest alpha, and was testing the new vbr mode. I decided to like it (_a lot_), since it's 3x faster than --vbr-old (!!). I did some reading up on the list, but I cannot find an answer to some Q's, maybe someone can address them, thanks 1- What was the reason/goal of the new VBR? (speed?, different V1->V9 scale?) 2- Same kind of bug here (I think) than in the --vbr-old (which was fixed by Robert in no time :)): E:\lame-alpha>lr -V1 -mj -h -b128 teenyweenytinybug.wav LAME version 3.86 (alpha 1) (www.sulaco.org/mp3) Encoding teenyweenytinybug.wav to teenyweenytinybug.wav.mp3 Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG1 LayerIII ( 6.0x estimated) qval=2 Frame | CPU/estimated | time/estimated | play/CPU | ETA 53/53(100%)| 0:00:01/ 0:00:01| 0:00:01/ 0:00:01|1.6798| 0:00:00 - bitrate statistics - [kbps] frames 3243 (79.6%) 40 4 (7.4%) 48 1 (1.9%) 64 1 (1.9%) 80 2 (3.7%) 112 1 (1.9%) 128 2 (3.7%) So again, "-b128" ignored and this time in just about all mp3's, not only this one: http://users.belgacom.net/gc247244/extra/teenyweenytinybug.zip (1.666bytes) -- Thanks & Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] README.DJGPP
Hello Joshua, Wednesday, July 05, 2000, 8:51:56 AM, you wrote: JB> Was I reading a joke or what? I don't know about the "Crud" directory with JB> all of the *.c and *.h files... Or any of the other suggestions in this JB> readme. Why not use the Makefile? I know you have to download GNU make, but JB> it's all right there at the same place to download. You'd need gcc, JB> binutils, bash, (maybe shutils) but it's not that hard to get. It is MUCH JB> easier to download the binaries for the GNU programs you might need than it JB> is to go this route. Once you've got the source code, typing make works just JB> fine, I personally like to make some additional optimizations, but there is JB> nothing special that is needed. JB> Josh JB> -- JB> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) I just compiled 3.85beta using that README.DJGPP as S.T.L. described it, and I get about the same performance (Cel450) than the _ic version of Dmitry. Only thing I can say is that it says: quantize.c:1087: warning: `quant_compare' declared inline after being called , but all seems to work perfectly, so I'm really happy I don't need to install MSC6 after all :)) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] small bug in Lame VRB?
Hello Robert, Tuesday, July 04, 2000, 6:18:27 PM, you wrote: >> I will fix it in a few hours, when I'm home. >> Robert RH> I checked in a first fix, more tuning may be necessary. cool. Sad thing Dmitry Kutsanov has no more alpha's on his page. :( Traffic problems? Maybe host the download page on geocities or so. Be sure to place the complete page there, and not only the binaries. I've been kicked off several times because I used them as a file host... If I found myself a copy of MSC6, is compiling the encoder a simple matter? (like running a makefile or so?) Or are tweaks required to get the thing running? thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] I'd like some basic frame info
Hello, In order to give that idea I had last month about an "album-header", in order to complete (imho) mp3 as a platform to encode all kinds of cds seamlessly, as opposed to only non-live/mix cds given current implementation, a chance, I'd like to get some information :) [yes, it is english] I looked at the source of lame concerning the xing VBR tag, and I get what's in the 140 bytes past "Xing". My questions: -what's in the header data, in order to get a good mp3 frame, that plays .03secs of silence instead of garbage? (where do I look in the lame code for this?) -the xing VBR-tag frame is a 64kbit/s frame. What's the usable content (bytes)? -How big would the maximum info content be in a 44.1 320kbit/s frame (so everythinig beside header I assume?, and 320being the largest possible mp3 frame?). -What about 48kHz and alikes (does this interfere with info-content)? -Imagine I define a record structure containing all info I need for my header thingy, would it be possible/adviseable to use that huffman code in order to get the text fields smaller? Pro's / Cons? (I'm thinking no because of the relative (as compared to filesize) small gain vs the increased complexity/no plaintext.) sorry for all the basic nagging Q's, but I'm conducting my own feasibility study eh :) thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
