Re: [MP3 ENCODER] http://www.sulaco.org/mp3/gpsycho/quality.html
> I raise to 99.99%. It's 0:43...0:47 of "I wan't tommorow" from the album > "The Celt" performed by Enya. That explains why I haven't found it > yesterday. The are a lot of similar spots in a lot of Enya albums. "The Celts". :-) > :: > BlackBird.wav: Also distortions in the original PCM file in the > :: > right channel. Around 2 kHz I think. First I thought > :: > it is a MP3 artefact, then a bug in the PC sound > :: > card. But it isn't. > :: > :: MP3Enc sure has trouble with it while some other encoders don't. Very good test > :: wave. What is the bug in the original PCM file, anyway? > :: > I analyzed the chunk and found out what the noise is: > > It's a very small noise band at constant 12.00 +/- 0.03 kHz. > It is modulated in amplitude with some Hz and also swells up and down. > It is strong after ticks 4-6, 12-14 and 20-21 in the left, > and after ticks 5, 6, 13, 14 and 21 in the right. > > Level is around -40 dB peak. That's 24 dB above the floor and a lot of > decibels above the masking threshold (how many?). > > There is also a more constant 16.00 +/- 0.03 kHz signal at -54 dB (+10 dB > over floor), but this I can't hear it. > > The reverb of the drums is cutted at a little bit above 11 kHz (44.1 kHz/4?). > > May be it is a part of the piece of music, but it not sounds natural and > disturbs a little bit. I see. But anyways it does trigger some "bug" in MP3Enc! - Zia > > > -- > Mit freundlichen Grüßen > Frank Klemm > > eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] > phone | +49 (3641) 64-2721home: +49 (3641) 390545 > sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] hello? (CVS)
Is this the right address to post to the mp3encoder list? I didn't find anything that mentioned the address to post to for this list, so if it is... please respond! Just so it's not a complete waste of a message, does anyone know if I can get read access to the CVS server for LAME? (Whatever the CVS server may be =) I would like to download from there as I think a problem I'm having may be cleared up if I use a (very) developmental version... Thank you all! -joe -- 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
[MP3 ENCODER] more MMX DOS stuff
Well I've got some modifications to nasm.h and Makefile.DJGPP that should do the trick to get the MMX functions to work right, very simple, but it works... Makefile.DJGPP nasm.h
Re: [MP3 ENCODER] win32
I'm running the win32 compiles found on http://www.maindex.com/lame/ in Windows 2000. After encoding is complete, I get a table showing bitrates and percentages, but the linux versions I've compiled and ran always show and update this table while encoding, frame by frame. The win32 version should do this? >From: Mark Taylor <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: [MP3 ENCODER] win32 >Date: Tue, 22 Aug 2000 13:21:42 -0600 > > > > > Why do the win32 versions not show on the fly bitrate analysis for vbr > > files? > > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > -- > > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > > > > >It should work (win32, but not dos/win3.1) if LAME is compiled with: > >-DBRHIST -DNOTERMCAP > > >Mark > >-- >MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] win32
> > Why do the win32 versions not show on the fly bitrate analysis for vbr > files? > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > It should work (win32, but not dos/win3.1) if LAME is compiled with: -DBRHIST -DNOTERMCAP Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Nr. Frames in mp3 file
I think the only way is to find every frame, and analyse the header. It will give you the frame length with the formula mentionned earlier (sample_per_frame/sampling_frequency). Otherwise, you'll be missing the VBR aspect of files (unless you can get the 'real' bit rate). - Original Message - From: "Patrick Ndjiki-Nya" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 22, 2000 8:27 AM Subject: [MP3 ENCODER] Nr. Frames in mp3 file > > Hello, > > I'd like to determine the number of frames included in an mp3 file > given its size. Using the formula > File_Size/(1152*Bitrate/Sampling_Rate) always leads to a number of > frames that's smaller than the one indicated by an MP3 decoder > (eg. WinAmp) for the same file. Could someone help me out ? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Free Format problem
> > BIT_RATE = 1 means free format. > > This seems kinda confusing -- why use 1 to indicate free when MPEG uses 0? 0 is for 'reserved' (I'm not responsible of this part of the code). > > I've checked the file in hexadecimal, and sometimes I get > > frame header at 202 bytes from the previous instead of 405. > > So I was wondering if this is not a bug of lame or if the > > free format allow this (but I don't think so). > > > > The other possibility is that the real frame size is 202 > > bytes, but then would some of the frames would be separated > > by 405 bytes ? > > Doing the math: > > (576 samp/gr * 1 gr/fr * 62000 bps)/(8 bit/byte * 22050 samp/s) = 202.4 > byte/fr > layer-IIIMPEG-2 bitrateconversionsamp freq You're right ! The correct frame length was 205. I was looking for another same frame header the wrong way (I forgot the PAD_BIT could be different). > Given that this is non-integral, padding will sometimes occur. When the > padding bit is cleared, the frame size will be 202, and when it is set, it > will be 203. Thus, I surmise that there are no 405 byte frames - you just > aren't tracking syncs correctly. Are you factoring in the padding bit? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the "-mx" mode - different philosophy
> 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... > --- > Hi Roel, Problem is, this is a lot of work and it is not clear that it would really improve things. The hard part is how do you tell if M/S gives better results than S? The only way is by some measure of distortion - allowed_distortion. But as we know, all measures of distortion are just very rough guidelines - if they were really good, VBR would be pefect! Thus my fear is that if we use some function of the distortion, we will not be able to tell in a reliable way if mid/side sounds better than stereo. Here is what I would suggest: (I've done this many times: it is tedious and a lot of work!) Can you isolate the problems in velvet.wav to a few frames, and then look at them with the frame analyzer, both with m/s and s. If you find an example where LAME uses m/s when it sounds better with s, then you can compare the distortion numbers and see if they could be used to indicate that s would sound better than m/s. The best way I've found to isolate probems is to play back the file with mpg123, using the -k and -n options to play a shifting window of about 50 frames, to narrow the problem down to a range of just a few frames. Then take a look at those frames with the frame analyzer, but on the original .wav file not the mp3 file. (if you run it on just the mp3 file, the psycho acoustic information used to produce the mp3 file will not be available) You can see the number of bits allocated to each granule of each channel, as well as the amount of distortion. Some of the information in the outdated pull down help menu might be usefull, but look instead for the cryptic line that says something like: FFT0 pe=0.77K/1.7 n=5/5.9/16.9/-96.6 The first two numbers are the PE and the short block energy variation which are used to determine CBR/ABR bit allocations and if short blocks should be used. The next 4 numbers are the distortion. In this case, over = 5 (5 bands have quantization noise > masking) max_noise = 5.9 maximum (over all bands) of quantization_noise - masking = 5.9db over_noise = 16.9Divide this number by 5 (over) to get the average value of quantization_noise(db) - masking(db) in each band where quantization_noise > masking tot_noise = -96.6Divide by the number of bands to get the average value of quantization_noise(db) - masking(db) in all bands. tot_noise is not that usefull since there will always be a couple of bands which have very little quantization noise and they skew the average downward. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] win32
> Why do the win32 versions not show on the fly bitrate analysis for vbr > files? They do. Try the one located on mp3-tech.org, and you'll see bitrate analysis Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib layer I/II decoding
> > I had a problem with some files to compute the length in second of a > > frame. I was using various Layer III format and is some cases the formula > > "frame_time = samples / frame_per_second" wouldn't give me the right > > length. I assume it might be comming from this LSF. > > How do you calculate frame_per_second? > > A better formula would be > > frame_time = frame_samples / sampling_frequency > > to get frame_time in seconds. Actually what I told was wrong. I was using this formula, but sometimes with wrong frame_samples values. > The above formula will work regardless of bitrate, free format or otherwise. Right. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Free Format problem
Thanx, that was the info I was missing. Now I get the track length on every example I had (some with free format too, some with different sampling freq, some with different bit rates) - Original Message - From: "Mark Taylor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 21, 2000 6:25 PM Subject: Re: [MP3 ENCODER] Free Format problem > If sample_freq < 32khz, samples per frame = 576 (not 1152)! > > This the the so-called 'LSF' extension of MPEG: > > 32khz - 48khz: MPEG1 Layer 3 1152 samples per frame > 16khz - 24khz: MPEG2 layer 3 576 samples per frame > 8khz - 12khz: MPEG2.5 layer 3 576 samples per frame. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] win32
Why do the win32 versions not show on the fly bitrate analysis for vbr files? Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: Digital downsampling of mp3s?
> > In the last episode (Aug 22), Jaroslav Lukesh said: > > It should be maybe possible in wavelet transform, but not in discrete > > cosinus. You should wait for wavelet encoder and decoder... > > > > Or you should use ;-)) > > > > lame --decode x.mp3 - | mp3enc31 -sti -of x.small.mp3 -esr 22050 -qual 9 -bw 11025 >-br 64000 > > I used to do that, but have found that lame doesn't do too badly on low > bitrates nowadays: > > lame -a --abr 22 --lowpass 5.7 --resample 22.050 -S --mp3input input.mp3 output.mp3 > > sounds very good. The most important value for me is the lowpass > frequency; set it so the "twinkling" artifacts aren't too annyoing. > > Dan Nelson > [EMAIL PROTECTED] I tend to agree: With a proper lowpass filter setting, LAME can get pretty close to the quality of mp3enc at low bitrates. One reason mp3enc might still have an edge is that for low bitrate stereo encodings, it uses intensity stereo, something LAME still does not have. Also, just a few days ago Robert discovered a bug which was causing stereo MPEG2 encodings to not use mid/side stereo as often as possible. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] attitude
> Frank: if your point is that a compliant bitstream is generally not the > best sounding one (where 'best' is defined by your taste), your point is now > well taken, and we can all read up on more effective interpolation schemes > to our hearts' content. If, however, your point is that Rob was wasting his > time by doing the compliance testing, your point is not well taken; many > people on this list actually appreciate and encourage this sort of selfless > activity. ISO 11172-4 may seem or even actually be stupid (it is from ISO, > after all), but it's what we have to work with, for better or worse. I don't think that Frank was trying to reduce the value of Rob's test. He just explained why this ISO compliance is not completely defining a standard of quality. Please let's try to stay gentle on this list, we're not on a vqf.com or dmusic.com message board! Another point about it is that in english, it seems that a lot of things like "in my mind", "in my opinion",... must be used in order to not beeing perceived as beeing rude, but it's less evident in other languages and not necessary a reflex for non-english people writing in english. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
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/ )
[MP3 ENCODER] Re: Digital downsampling of mp3s?
In the last episode (Aug 22), Jaroslav Lukesh said: > It should be maybe possible in wavelet transform, but not in discrete > cosinus. You should wait for wavelet encoder and decoder... > > Or you should use ;-)) > > lame --decode x.mp3 - | mp3enc31 -sti -of x.small.mp3 -esr 22050 -qual 9 -bw 11025 >-br 64000 I used to do that, but have found that lame doesn't do too badly on low bitrates nowadays: lame -a --abr 22 --lowpass 5.7 --resample 22.050 -S --mp3input input.mp3 output.mp3 sounds very good. The most important value for me is the lowpass frequency; set it so the "twinkling" artifacts aren't too annyoing. -- Dan Nelson [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] MPEG audio decoder compliance
Howdy, > :: My purpose was to measure the computational accuracy of > audio decoders in the > :: manner described by ISO/IEC 11172-4. > :: > The result is a ISO/IEC 11172-4 compliant decoder. It's not > so much better > than a ISO 9001 certificate. A decoder with a bug fails the test. > But not vice versa. What would 'not vice versa' mean in this case? That a decoder without bugs doesn't pass the test? (Is this possible?) That a decoder with bugs can pass the test? (This is certainly possible (as Mark pointed out much earlier), but also certainly beyond the scope of Rob's current effort.) > :: To do so requires obtaining the PCM output from the > decoder, in whatever > :: precision. You'll notice I was only able to obtain 16-bit > precision from > :: most of the decoders, so for these decoders the > quantization noise is > :: presumably +/- 1.526e-5 in the best case, and indeed this > shows in the > :: results. The compliance tests, however, allow this to be up to +/- > :: 6.104e-5 and still be compliant. > :: > This is the RMS errors, not the audible noise. Especially on > 96 kHz (MP3 > can't handle this) there are approximately 50...55 dB between > RMS error and > audible noise. I don't think Rob ever claimed to be measuring audible noise - he is just checking compliance, which deals with matching PCM output, i.e. RMS error. > :: I think it's clear that output with more precision can > reduce the resulting > :: quantization noise, but that doesn't negate the test > results for decoders with > :: less precision, nor should the quantization strategy have > any bearing on the > :: tests. > :: > There are alot of buggy MP3 decoders out there. Well, duh. And compliance checking is one way to find them. > But calculating the audible distortion by the RMS of the > differences has > nearly nothing to do with human perception. Perhaps you should explain this to the MPEG committee. > But with round-to-nearest-integer you only got a usable > dynamics of 55 dB > (CCIR). With better methods you can increase this value up to > 86 dB (CCIR). These numbers fly in the face of the standard statistical modelling of fixed quantization, which claims (under a number of assumptions, some of which could be bad in this particular case, I suppose) that SNR(dB) = 6B - 7.2, where B is the number of bits. [Rabiner & Schafer, Digital Processing of Speech Signals, p.185, c. 1978] I guess I'll have to check out the CCIR definitions when I get some time. > :: signal and the reference output signal, both of which > have the same sampling > :: frequency. If you want to optimize the output quality by > resampling to a > :: higher frequency based on internally higher precision > samples, fine, but this > :: doesn't change the fundamental computational accuracy of > the decoder as > :: measured by the compliance test. > :: > :: Do you disagree, or aren't the compliance test results > therefore valid? > :: > compliance test are simple statically tests. Not less and not > a little bit > more. I'm not sure when anyone claimed anything different? > :: FYI, the strategy I took with MAD was to provide full > (28-bit) internal > :: precision output from the decoder library API and let the > application decide > :: how to scale or resample it to however many bits of > precision it wants. So > :: > I want 86 dB (CCIR). That can be achived with 16 bit/44.1 kHz HQ > quantization, by 13 bit/96 kHz HQ quantization or by 22 bit/44.1 kHz > round-to-nearest-integer quantization. Perhaps you should do us all a favor and come up with you own compliance testing standard then? One which could evaluate how closely each decoded file sounds like the reference decoded file? This is an extremely difficult problem, as I'm sure you know. > You don't need a color printer with (2^24)-1 color cartridges > to print a true > color picture. 4 or 7 are enough. > > Buy a sound card and listen to the test files !!! Why? Rob is just trying to check MPEG compliance, which, as you have overstated, has nothing to do with how files sound. (This is hardly true, but, given that compliance can be checked without listening to the files, is effectively unimportant.) Not meaning to flamebait, but this thread seems to be generating an awful lot of heat at this point, and not much light. Frank: if your point is that a compliant bitstream is generally not the best sounding one (where 'best' is defined by your taste), your point is now well taken, and we can all read up on more effective interpolation schemes to our hearts' content. If, however, your point is that Rob was wasting his time by doing the compliance testing, your point is not well taken; many people on this list actually appreciate and encourage this sort of selfless activity. ISO 11172-4 may seem or even actually be stupid (it is from ISO, after all), but it's what we have to work with, for better or worse. Rob: Thanks for your work and your patience - I appreciate it. Ale
Re: [MP3 ENCODER] Digital downsampling of mp3s?
Jaroslav Lukesh schrieb am Die, 22 Aug 2000: > lame -h -m j -b 64 --voice --noshort --resample 22.05 --lowpass 11.025 > --lowpass-width 0 --mp3input x.mp3 x.small.mp3 why not lame --preset fm -h -k x.mp3 x.small.mp3 ??? but I would not use -k there. > Note that --voice options sounds better with bitrates <= 64k. mainly because the short block detection isn't tuned for LSFs. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] the "-mx" mode - different philosophy [off topic]
Howdy Gabriel, > First, please note that it has been a long time I didn't really looked > inside of the Lame code, so I'll perhaps tell a few wrong statements. > (btw, please could anyone explain me when to use the word "tell" and > when "say"?) Hmmm... That's actually kind of tricky. Neither is really appropriate in the phrase above, though I suppose 'say' would be less wrong sounding. Both say and tell imply speaking, but tell has more of the sense of the conveying information part of speaking (tell a story, tell time), while say is more connected with the physicality of speech and/or opinion (?) (what did/would you say, he said/she said). To tell is to recount or recall; to say is, broadly, everything else, but especially to opine or speak out loud. I'm just generalizing, though - there may be many exceptions. Anyway, I'd _say_, "First, please note that it's been a long time since I really looked at the Lame source, so I may (perhaps) misspeak myself," or, "...so I may make some misstatements (mistakes)." The grammar of the former is beyond my current ability for analysis; the latter is pretty straightforward subjunctive, just with a simpler/more generic verb. I doubt that helps, Alex -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] the "-mx" mode - different philosophy
I'm not equiped for listening tests here (only an awe64), but is the velvet problem the thing I'm hearing in the right channel? (or am I thinking I'm hearing something?) If this is the case, it seems to me that it's reduced in -m f, but the stereo image is also changed by this switch. If it's gone in forced mode, it could be a toggling problem. Roel, could you check this? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: [vorbis-dev] M/S encoding ?
> > From: Mark Taylor [mailto:[EMAIL PROTECTED]] > > > > MP3 does not allow mid/side stereo to be turned on and off on a band by > band basis (AAC does), > > Hmm, then what happens if a JS frame has both M/SS and IS enabled? In Layers > I and II, IS can be enabled across several fixed bands, I guess something > similar happens in Layer III? The lower bands get MS stereo and the upper bands get IS stereo. It is in the doc (11172-3). Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Re: [vorbis-dev] M/S encoding ?
> From: Mark Taylor [mailto:[EMAIL PROTECTED]] > > MP3 does not allow mid/side stereo to be turned on and off on a band by band basis (AAC does), Hmm, then what happens if a JS frame has both M/SS and IS enabled? In Layers I and II, IS can be enabled across several fixed bands, I guess something similar happens in Layer III? -- Mat. -- 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
Re: [MP3 ENCODER] Digital downsampling of mp3s?
| Like many people on this list (I imagine) I have a fairly substantial | collection | of good quality (-v --preset studio) MP3s encoded with lame. I'd love to be | able to be able to make them smaller to squash more musiconto my portable | MP3 player. | | Is it possible to have lame digitally resample an mp3 on a frame-by-frame | basis? Although granted, the quality wouldn't be as good as a 'slow' | encoding, | I'd imagine this could be extremely fast! no way here :-( It should be maybe possible in wavelet transform, but not in discrete cosinus. You should wait for wavelet encoder and decoder... Or you should use ;-)) lame --decode x.mp3 - | mp3enc31 -sti -of x.small.mp3 -esr 22050 -qual 9 -bw 11025 -br 64000 (ech... commercialcrippleware, 30 sec limit - but you can cut wav and glue mp3s :-)) (with very small tick each 30s)... BTW, Im not try this "cutting" under linux, should kill -HUP pid after each (say) 28sec help? will sounds much better than lame -h -m j -b 64 --voice --noshort --resample 22.05 --lowpass 11.025 --lowpass-width 0 --mp3input x.mp3 x.small.mp3 Note that --voice options sounds better with bitrates <= 64k. You can test options like --cwlimit (default is cca 8, yoiu can test it from 0 to 11.025). Regards Jaroslav Lukesh, K-net -- http://www.k-net.cz Multimedia, Networking, Communications Windows terminals, NC computer hardware and software -- note: (Bill) Gates to Hell! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Re: RH_AMP Option
> If you make a "grep RH_AMP *.c" over all C-sources you will find out, > that it enables a different amp_scalefac_bands() in quantize.c and > makes a little psymodel tweak in psymodel.c. > > > Ciao Robert Thank you for your quick replay. Actually, most of the people might think 'thank you' mail is just annoying but my Mum is quite strict on these stuff. ;o) So, thank you Robert, and good luck on the development. Cheers, Keeshond. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Digital downsampling of mp3s?
> From: Stephen Kennedy [mailto:[EMAIL PROTECTED]] > > Is it possible to have lame digitally resample an mp3 on a > frame-by-frame > basis? Although granted, the quality wouldn't be as good as a 'slow' > encoding, > I'd imagine this could be extremely fast! Hmmm, I doubt it. The psychoacoustic model needs the original signal in (at least) FFT form. I don't think MDCT -> FFT can be done directly, so you'd need to go MDCT -> time domain -> FFT, i.e. full decode followed by FFT. You probably wouldn't gain any speed at all. I suppose you could disable the psymodel, but at low bitrates that's a recipe for terrible quality... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MPEG audio decoder compliance
> :: FYI, the strategy I took with MAD was to provide full (28-bit) > :: internal precision output from the decoder library API and let > :: the application decide how to scale or resample it to however > :: many bits of precision it wants. > :: > I want 86 dB (CCIR). That can be achived with 16 bit/44.1 kHz HQ > quantization, by 13 bit/96 kHz HQ quantization or by 22 bit/44.1 kHz > round-to-nearest-integer quantization. > > You don't need a color printer with (2^24)-1 color cartridges to print a > true > color picture. 4 or 7 are enough. Frank, that sounds you are thinking about dithering? FYI http://www.digido.com/ditheressay.html#RTFToC8 Ciao Robert -- Sent through GMX FreeMail - http://www.gmx.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the "-mx" mode - different philosophy
Hi Gaby! > > 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) > > not so slower, if both sets of data are already computed Psychoacoustics are calculated for stereo and mid-side stereo frames. Then a decision is made using masking ratios calculated in GPSYCHO. The iteration loops quantize either stereo frames or mid-side frames. CBR/ABR: bitallocation for side channel uses energy ratios from GPSYCHO VBR: every channel can get as many bits as needed, in case there is no bit pressure like 4095 maximum or if the largest allowed frame would not provide enough bits. I think, if there are really cases where MS frames would take a lot more bits than ST frames, then we can tune our switching criterion and see for example how the energy ratios (already calculated in GPSYCHO) look like. Maybe another constraint for energy ratios would solve the switching problems without the need to quantize all four channels. Ciao Robert -- Sent through GMX FreeMail - http://www.gmx.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Digital downsampling of mp3s?
Hello 'lamers', Like many people on this list (I imagine) I have a fairly substantial collection of good quality (-v --preset studio) MP3s encoded with lame. I'd love to be able to be able to make them smaller to squash more musiconto my portable MP3 player. Is it possible to have lame digitally resample an mp3 on a frame-by-frame basis? Although granted, the quality wouldn't be as good as a 'slow' encoding, I'd imagine this could be extremely fast! Stephen. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the "-mx" mode - different philosophy
First, please note that it has been a long time I didn't really looked inside of the Lame code, so I'll perhaps tell a few wrong statements. (btw, please could anyone explain me when to use the word "tell" and when "say"?) > 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. There is also another parameter: trying to minimise the toggling between s and ms > 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. Does this really happens in vbr? Could you please try using Mp3x and see if the same frame could sometimes use more space in ms than in s? It seems so strange...If it's true, I think that there is a mistake somewhere in the ms bit allocation > 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. Not always: I think that if we got something like s-s-s-ms-s-s it will be converted before bitstream formatting to s-s-s-s-s-s in order to reduce the togling artefact. > Big advantage of this prediction method is the speed. I don't know if it's still the case, but in the past both ms and s data were computed as the mode of a frame could be changed according to the next one. > 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) This Velvet track must have some (perhaps not yet known) other difficulties, as the results are quite catastrophic for every encoder, including mp2 ones. > 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. This is, to my mind, the goal of -mj, so any change should be made into -mj > 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) not so slower, if both sets of data are already computed just my 2 centimes about it... Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: Difficult examples, Lame fails, FhG not
:: >Another point: I notice you changed the encoding status display to
:: >update every 2 seconds, rather than every 100 frames. Any reason for
:: >this? I prefer 100 frames because I like looking and nice round
:: >numbers, and it doesn't impact the speed. Also, to do the 2 second
::
:: I also noticed this, and imho it's much better than a fixed number of frames,
:: mainly because you will get a steady refresh no matter how fast/slow your cpu
:: is .. ie, on slow machines you don't have to wait ages to see how far it got,
:: and on fast machines the numbers won't change faster than you can read... ;)
::
Depending on lame options, sample frequency, quality settings and CPU speed
the display output speed changes from 10 displays per second until a display
every 20 seconds. There was always a patch reducing the 100 to 50 under
special circumstances, not very nice.
Every 2 seconds is a compromise between 1 second (nice fast) and 5 seconds
(it's a liitlleee biiit slooow). Also it's not exactly 2 seconds. It's 2
seconds plus time of the display update. So if display update takes 2
seconds the engine still works. But lame capable machines should not have
problems with output speed, a -DDISPLAY_UPDATE_TIME=60.0 is also possible.
On the other hand side, update starts using termcaps if available. This
reduces output, so update via slow internet lines may be becomes faster.
Maybe all console output should be handled in one source file?
Also, when the lame engine is nearly locked (bad convergence) you got a
message every frame instead of every 2 minutes. This may prevents from
typing ^C. Also you got the current frame number.
If also the verbose code should be thread save, there are a lot of other
variables. May be they should be collected in a gfpv structure.
:: I prefer 100 frames because I like looking and nice round numbers, and it
:: doesn't impact the speed.
::
On my 2 years old computer the average update speed hasn't changed so much.
Sometime it is faster, sometimes slower.
:: constants) to make the library thread safe. However, the whole
:: timestatus.c package is not thread safe, and the status display
:: wouldn't be used by someone doing multiple encodings within a single
:: executable, so it doesn't really matter.
Code like that?
typedef struct {
FILE* device;
const char*cursor_up;
const char*erase_end_of_line;
time_t last_display_update;
unsigned long last_total;
unsigned int last_kbps;
unsigned long last_frame;
unsigned long brhist_count [15];
unsigned long brhist_count_max;
unsigned brhist_vbrmin;
unsigned brhist_vbrmax;
char brhist_kbps[15] [4];
char brhist_bar [BRHIST_BARMAX + 1];
char stderr_buff[576];
} gfpv;
...
typedef struct {
gfpv* visual;
} gfp;
...
if (gfp -> gfpv) {
fprintf ( gfp -> visual -> device, "Hallo%s\n", gfp -> visual -> erase_end_of_line
);
}
...
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MPEG audio decoder compliance
:: :: FK> May be mpg123 in october. I try to convince Michael Hipp to use my :: FK> ultra-fast round-to-nearest-integer routines°°). If he uses these :: FK> routines, it becomes very easy to use other quantization routines by :: FK> simple replacing 2 routines by another and recompiling. Currently the :: FK> quantization is spreaded around the whole program. :: :: I guess I don't get your point. I understand your concern about quantization :: noise in the last step of the decoding process, but this seems unavoidable, no :: matter how you go about it. :: Yes. :: The amount of quantization noise is directly related to the precision of the :: output, since as you noted, floating point output incurs no rounding. But even :: floating point output has only a certain level of precision, and quantization :: has already taken place. :: Yes. So I wrote in braces: first approach. :: My purpose was to measure the computational accuracy of audio decoders in the :: manner described by ISO/IEC 11172-4. :: The result is a ISO/IEC 11172-4 compliant decoder. It's not so much better than a ISO 9001 certificate. A decoder with a bug fails the test. But not vice versa. :: To do so requires obtaining the PCM output from the decoder, in whatever :: precision. You'll notice I was only able to obtain 16-bit precision from :: most of the decoders, so for these decoders the quantization noise is :: presumably +/- 1.526e-5 in the best case, and indeed this shows in the :: results. The compliance tests, however, allow this to be up to +/- :: 6.104e-5 and still be compliant. :: This is the RMS errors, not the audible noise. Especially on 96 kHz (MP3 can't handle this) there are approximately 50...55 dB between RMS error and audible noise. :: I think it's clear that output with more precision can reduce the resulting :: quantization noise, but that doesn't negate the test results for decoders with :: less precision, nor should the quantization strategy have any bearing on the :: tests. :: There are alot of buggy MP3 decoders out there. But calculating the audible distortion by the RMS of the differences has nearly nothing to do with human perception. But with round-to-nearest-integer you only got a usable dynamics of 55 dB (CCIR). With better methods you can increase this value up to 86 dB (CCIR). :: signal and the reference output signal, both of which have the same sampling :: frequency. If you want to optimize the output quality by resampling to a :: higher frequency based on internally higher precision samples, fine, but this :: doesn't change the fundamental computational accuracy of the decoder as :: measured by the compliance test. :: :: Do you disagree, or aren't the compliance test results therefore valid? :: compliance test are simple statically tests. Not less and not a little bit more. :: FYI, the strategy I took with MAD was to provide full (28-bit) internal :: precision output from the decoder library API and let the application decide :: how to scale or resample it to however many bits of precision it wants. So :: I want 86 dB (CCIR). That can be achived with 16 bit/44.1 kHz HQ quantization, by 13 bit/96 kHz HQ quantization or by 22 bit/44.1 kHz round-to-nearest-integer quantization. You don't need a color printer with (2^24)-1 color cartridges to print a true color picture. 4 or 7 are enough. Buy a sound card and listen to the test files !!! -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[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: [MP3 ENCODER] RH_AMP Option
> Hi, there. > > Could someone explain to me what this new option called 'RH_AMP' > of LAME CVS version means? Makefile for gcc tells me just > 'special noise calculation.' > However, I have no idea about what exactly this means. Oh, well... > > Thank you in advance. > > Keeshond. If you make a "grep RH_AMP *.c" over all C-sources you will find out, that it enables a different amp_scalefac_bands() in quantize.c and makes a little psymodel tweak in psymodel.c. Ciao Robert -- Sent through GMX FreeMail - http://www.gmx.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] sync-word (Was "Free Format problem")
> From: "Shawn Riley" <[EMAIL PROTECTED]> > > Alex wrote: > > > Thus, I surmise that there are no 405 byte frames - you just aren't > > tracking syncs correctly. > > Does that mean that each frame has to have a whole number of bytes Yes, Layer III works with 8-bit "units". > therefore that the sync-word is only allowed to start on the first bit of > any byte? Normally yes, but I guess it could become misaligned if the stream were corrupted in transit... would be interesting to see how many decoders can cope with that. :) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] ACM Driver
In my opintion VBR encoding can be done with an ACM driver (as you might know, vorbis atm is only VBR). The most severe problem with my ACM driver atm is vorbis' block size, which is rathar large compared to MP3 (about 4K, MP3 has blocks around 512B). If you are interested in the sources, the latest is at http://sourceforge.net/projects/vorbisACM. If somebody would like to start a spinoff, I will be glad to give some support. br, Florian > There has not been one written for LAME. Apparently the Windows ACM doesn't > support VBR encoding and LAME wasn't completely thread safe at the time so > it was abandoned. > > Ironically, a few days ago it was mentioned that someone (you?) was working > on an ACM for Ogg Vorbis and that the author may like to share his code to > help with a LAME ACM. > > Cheers, > Ross. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Florian Bruckner > > Sent: Tuesday, 22 August 2000 02:54 > > To: [EMAIL PROTECTED] > > Subject: [MP3 ENCODER] ACM Driver > > > > > > Hi all, > > > > recently I browsed the list archives and saw that there somebody was > > creating an ACM driver. Has this ever resulted in a piece of > > code? If so, > > I'd like to have a look at it. I'm doing an ACM driver for Ogg vorbis > > (www.xipg.org/ogg/vorbis) and am interested how others solved > > the problems I > > am facing. > > > > best regards, > > Florian > > > > -- > > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] sync-word (Was "Free Format problem")
Alex wrote: >Thus, I surmise that there are no 405 byte frames - you just aren't tracking syncs correctly. Does that mean that each frame has to have a whole number of bytes, & therefore that the sync-word is only allowed to start on the first bit of any byte? Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] RH_AMP Option
Hi, there. Could someone explain to me what this new option called 'RH_AMP' of LAME CVS version means? Makefile for gcc tells me just 'special noise calculation.' However, I have no idea about what exactly this means. Oh, well... Thank you in advance. Keeshond. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
