[MP3 ENCODER] Unbalancedl VBR bitrate stats
These days (using -V5 -q2 --nspsytune -Y) I get what I consider an unbalanced graph where it rarely uses over 160bps. I use to get a more logarithmic looking graph. Is this normal. 56 [0] 64 [ 10] * 80 [ 435] *** 96 [ 2031] 112 [ 3557] %*** 128 [ 9930] %%** 160 [11786] %* 192 [1] * 224 [0] 256 [0] Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] KLEMM_??
A few days ago, Frank said one of his routines should have been included by default in LAME when KLEMM_01 (new ath routine) was included otherwise the new ath reduces quality. Has this been done yet? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
I think Roberts code should be included and implemented with a switch so us "non-compilers" can test it. Ross. Roel VdB wrote: Hello Robert, Thursday, September 28, 2000, 8:12:59 PM, you wrote: RH Dmitry schrieb am Don, 28 Sep 2000: but what version i have to upload??? from project file or from makefile??? with 'Robert's alternate code' enable or disable??? RH Well, officially the one with 'Robert's alternate code' RH commented out. Sorry for the confusion. Robert, please consider defaulting the enhancements. It improves the 'velvet' track quality considerable in JS mode. Is there a downside to this 'alternate code'? -- Best regards, Roel mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] realtime encoding specs ?
Title: RE: [MP3 ENCODER] realtime encoding specs ? Mark Powell wrote: That was with the options: -V1 -b128 -mj -h under FreeBSD. It wasn't a competition I was just giving him some empirical evidence to work with :) My reults were based on -V4 -b32 -mj -h Ross.
Re: [MP3 ENCODER] post-encoding mp3 amplification
Pierre Hugonnet wrote: It seems to be for DOS/WIN only... Is there something equivalent for Unix ? I don't think so though someone may be working on it. The utility mentioned, however, works fine with a little WINE. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] realtime encoding specs ?
Mark Powell wrote: FYI My PIII 583MHz (not Coppermine) provides ~1.5x normal speed. On Win98 the new VBR encodes at ~1.1x on my AMD K62-428. CBR is a bit faster. K62 is known for slow FPU so I would expect much better from the P3. I think the LAME website says P2-266 will encode CBR realtime! Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] post-encoding mp3 amplification
Or if you want a Windows GUI app then MP3Trim is good (http://mp3trim.8m.com) Ross. Mark Taylor wrote: Is it theoretically possible to amplify the sound in a mp3 file without reencoding it? What would be the quality loss of this operation? Yes: modifying the global_gain field in each channel of each granule in a Layer III frame has the effect of amplifying or diminishing the decoded signal in increments of 1.5 dB. There is apparently no quality loss associated with this change as long as the signal is not amplified so much as to cause clipping. This utility will do exactly that: http://www.chat.ru/~lrsp/English/index.html Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Congradulations Mark (Off Topic)
We are expecting our second in November. From my experience, I suspect we will be hearing less from you in the next few months. You will most likely be sleeping in your spare time! Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] ACM Driver
Title: RE: [MP3 ENCODER] ACM Driver 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/ )
Re: [MP3 ENCODER] Xing header problem
Bill Currie wrote: Now all I need is to find (or write) a program to create a correct Xing header. I really don't feel like re-ripping all those cds (about 30). I need one of those too! If you write it, I'll test it :) Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] The best decoders
I tried the in_mpg123 Winamp plug-in for my FM radio station a few weeks ago but I had to switch back to nitrane. If it finds a non-existing file in the playlist it just stops playing -- doesn't advance to the next song. I occasionally have this problem so I can't use it. I e-mailed Shibath but I haven't seen any progress. Ross. Eric wrote: ...In fact I had switched from Winamp 2.5 to 2.22 from what I had read on David's website.Now I shall try Shibath's plug-in too. I thought from your response you had even later information,, -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] ABR and VBR
Do a search of the mail list archive where it has been discussed in detail. DataFlow wrote: could anyone tell me what the difference is between ABR and VBR?(maybe a URL where I can learn more?) I know VBR stands for Variabele Bitrate, it means that every MPEG-frame can have a different # kbits/sec.Does ABR mean Average Bitrate or so? thanx,DataFlow -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi PCM file coding and decoding
It would be easier/better to add multiple file support to LAME. It has been previously mentioned that BladeEnc has this solved the gap problem with an option to internally join all selected WAVs for the encoding process. Ross. Mathew Hendry wrote: From: Frank Klemm [mailto:[EMAIL PROTECTED]] I know there is a project to avoid pauses between tracks by extending the MP3 format with additional tags. But I don't understand why this is necessary and AFAIS the handling is a little bit difficult. [snip suggested support for multiple filenames] This seems to assume that you have to encode each track individually. Why not use one big wav, encode that, and split it afterwards? This requires no encoder changes (will work with any encoder) and the tools already exist to do the splitting. Works for me... but I'm idly working on an "encoder wrapper" that simplifies the process wrapper file.wav file.cue will first invoke the encoder on file.wav, producing file.mp3, then split file.mp3 based on file.cue, adding id3 tags as it goes. It would then be quite simple to add support for your approach wrapper file1.wav [file2.wav [...]] and work with a cue sheet generated on the fly. Seems to me to be a cleaner approach overall. OTOH I'm not sure if .cue files are well-supported on platforms other than Windows. Can cdparanoia etc. be configured to generate them? -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Mayah EditPro
Thanks E. I like the term "fixed". "E. Zann" wrote: Hi folks, Just found this link to Mayah EditPro: http://cooler.irk.ru/sound/software/editors/edpro22.zip This version is fixed by Radium, here is what they say about it: "Mayah EditPro is an MP3 file editor. It allows you to edit mp3 files directly, meaning there is no lengthy 're-encoding' or accumulated quality loss when saving a file. Features : Cut, copy and paste of mp3 frames, auto fades, volume editing, markers and more. (Retail $500) More info at http://www.mayah.com/english/editpro.html" Hope this was not too much off-topic, though :) Greetings, -E. [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] corrupt mp3 finder
Try http://www.geocities.com/MP3utility Cheers, Ross Levis. Francois du Toit wrote: 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 to check my MP3's without Nero. I thought someone out there should know something ThanxFrancois -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 32 or 44.1kHz for 128 kbit/sec mp3s fromsoundcard?
"Eric.Howgate" wrote: Whilst sample rate is up for discussion, - could somebody confirm what is the quality of broadcast FM music is in terms of sample rate ? When recording from the radio via line-in Cool Edit shows the source as 16 bit stereo @ 32KHz. It is an analogue (analog for you Americans) transmission so there are no sample rates. Although a lot of radio stations would be using 16-bit 32khz internally for storage on hard disk. Also I saw a claim that FM has a frequency cut-off at 14.5KHz - is this true ? In New Zealand and most countries the cut-off is 15khz. Would there be any point in saving such files as 44.1KHz audio before converting to mp3 ? Probably not. My (limited) understanding is that FM broadcasts are compressed before transmission and the datastream is decoded by the tuner/receiver. If so what is the encoding process used ? There is usually compression involved but not the way you think. The audio waveform is compressed before broadcast so that the quieter parts are made louder. The only encoding/decoding going on is for stereo transmission which I won't go into here. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Difference between 8 and 16 bit quality
Title: RE: [MP3 ENCODER] Difference between 8 and 16 bit quality I thought the number of bits refers to the number of variations in volume from silence to maximum. 16-bit providing 65536 steps and 8-bit providing only 256. I would think it would be difficult to hear the volume change on an 8-bit tone when moving up 1 step, from say 128 to 129. It would be like a TV having 256 volume positions. I've come across some annoying TV's with only about 16 volume positions. Increase a notch and it's too loud and decrease and it's too quiet. I don't notice much difference changing my Winamp to 8-bit MP3 decode. So it begs the question; would reducing the audio bits provide more space to increase sound quality on lower bitrates? Ross.
RE: [MP3 ENCODER] lame exit problems
Title: RE: [MP3 ENCODER] lame exit problems This should work. Right-click the icon at the top left of the DOS window. Select Properties in the Program tab select Close on Exit. This will create a LAME.PIF which Windows should recognise when loading LAME.EXE. Ross. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joshua Bahnsen Sent: Monday, 10 July 2000 14:56 To: [EMAIL PROTECTED] Subject: [MP3 ENCODER] lame exit problems Is there any way to force a DOS box close after lame has completed encoding? With the Windows binary, it exits properly but with the DOS one it just says Finished and the box stays open. So if I'm using the DOS version to encode with say audiograbber, I can never get to the next track without manually closing the box. Josh -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] ACM (2)
It was Acy Stapp not Mark T that had a look at doing it but apparently the Windows ACM doesn't support VBR and I think it was abandoned. I'm not sure where the problem is because I'm fairly sure that the Fraunhofer ACM does play VBR MP3 WAV files. I haven't found a utility that can add a correct WAV header to a VBR MP3. Someone recently requested this option be added in LAME -- which I second. Ross. Cavallo de Cavallis wrote: No one replied to the previous mail bout this, btw let's try again :) how is going on the ACM driver for windows ? I supposed Mark was workin on it, or have u stopped the "adapting" ? Cavallo de Cavallis [EMAIL PROTECTED] =-=--=--=--=--=--=--=--=--=--== = http://www.s0ftpj.org = = Digital Security for y2k = ==-=--=--=--=--=--=--=--=--=-== "Knowledge chases me, but i'm faster" "La Sapienza mi insegue, ma io sono piu' veloce" [Anonymous] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Marks new VBR now the default
That's a controversial move IMO. The advantage of true VBR is that more complex recordings use higher bitrates and less complex have low bitrates and filesizes with roughly the same amount of distortion. With Marks ABR the operator chooses the bitrate, so complex recordings have high distortion, and less complex recordings are wasting disk space. I presume with the availability of vbrtest that some more work will be done on GPSYCHO to correct the problems? What might work at this stage is a mixture of both. There would be some opposition because it would take a lot longer and require 2 passes through the source file so couldn't be used from pipes. I propose a dummy VBR encode pass that simply calculates the average bitrate for the entire song. Then encode the song with ABR at the calculated rate. This is assuming that GPSYCHO calculates the distortion correctly most of the time. Ross. Robert Hegemann wrote: I just made Marks new VBR routine the default one. If someone needs the old one, just replace -v with --vbr-old. lame -v x.wav - calls lame to use Marks new VBR lame --vbr-old x.wav - calls lame to use the old VBR -- e-mail: [EMAIL PROTECTED] homepage: http://linux.unixcity.de/catwalk/index.html -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] ACM (2)
Mathew Hendry wrote: From: Ross Levis [mailto:[EMAIL PROTECTED]] apparently the Windows ACM doesn't support VBR and I think it was abandoned. I'm not sure where the problem is because I'm fairly sure that the Fraunhofer ACM does play VBR MP3 WAV files. It does, because the *output* is CBR. That's where the limitation lies. Of course the output will be CBR. As I understand it, all sounds regardless of codec are effectively decoded to PCM before being sent to the soundcard. So where is the limitation then? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] About Vorbis
Mark Taylor wrote: I like this quote: --start quote--- According to Brandenburg, the ISO asked Fraunhofer to develop sample encoding and decoding software as a tool for industry to learn how to use MP3. The source code -- the underlying instructions -- for these programs was carelessly placed on an insecure university server, where it was later obtained by a hacker in Amsterdam known as SoloH. (Brandenburg says the download was not authorized but also not illegal.) Using SoloH's source code, coders across Europe and the United States wrote and gave away MP3 software of their own, creating -- without the participation of the music industry -- the base for today's explosion of online music. --end quote--- I thought the ISO source code was freely available from Fraunhofer's ftp site well before SoloH released his encoder, but then it was a few years ago now and time maybe playing tricks. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Portable MP3 Players
Jaroslav Lukesh wrote: http://www.ntelec.com.hk/ 3xAA battery Shame this one doesn't support CD-RW or I would attempt a purchase myself. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Xing VBR header
Slightly off topic but does anyone know of utility to add the Xing VBR header to a headless VBR MP3. Some time ago I used a LAME front-end to encode a number of CDs and it must have enforced the -t switch. It is a major inconvience for producing scheduled playlists for my radio station. Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] -Y not producing similar results
Mark Taylor wrote: -Y enables the true noise shaping VBR mode. It should give similar results to #1, but be much faster. Not similar results at all. -Y is producing much larger files with less spread across the bitrates. A graph of the -Y results doesn't look natural in my opinion with the sharp drop after 160. There is also less change to average bitrates when changing -V values. -V9 just droped the average by 20kb/s as shown (5 minute song). Standard VBR (-V4 -mj) 0 - 0 - 0.0% 32 - 45 - 0.3% 40 - 21 - 0.2% 48 - 16 - 0.1% 56 - 24 - 0.2% 64 - 63 - 0.5% 80 - 379 - 2.9% 96 - 1407 - 10.8% 112 - 4719 - 36.3% 128 - 4188 - 32.2% 160 - 1064 - 8.2% 192 - 587 - 4.5% 224 - 306 - 2.4% 256 - 151 - 1.2% 320 - 40 - 0.3% Average bitrate: 126.2 (-V4 -Y -mj) 0 - 0 - 0.0% 32 - 24 - 0.2% 40 - 3 - 0.0% 48 - 4 - 0.0% 56 - 9 - 0.1% 64 - 42 - 0.3% 80 - 178 - 1.4% 96 - 588 - 4.5% 112 - 1912 - 14.7% 128 - 3806 - 29.3% 160 - 5187 - 39.9% 192 - 641 - 4.9% 224 - 293 - 2.3% 256 - 210 - 1.6% 320 - 113 - 0.9% Average bitrate: 144.9 (-V9 -Y -mj) 32 - 27 - 0.2% 40 - 3 - 0.0% 48 - 44 - 0.3% 56 - 69 - 0.5% 64 - 90 - 0.7% 80 - 709 - 5.4% 96 - 1408 - 10.8% 112 - 3220 - 24.8% 128 - 4969 - 38.2% 160 - 1810 - 13.9% 192 - 499 - 3.8% 224 - 156 - 1.2% 256 - 6 - 0.0% 320 - 0 - 0.0% Average bitrate: 124.8 Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] What's Safe-VBR mode?
Mark? and any ideas when -Y will become default. Does it still need some testing or tuning? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] full huffman search for every loop
Takehiro Tominaga wrote: Full huffman search is still alpha status, and it sometimes lock up and is usually "painfully" slow. This feature will be available with the MMX enabled Huffman code search routine next weekend, I hope. But, I am not full time LAME programmer and LAME is only my hobby. I can't garantee the this plan :p Fair enough Takehiro. I look forward to testing it when it is available. Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Bug with -q1 (win32)
I've inadvertantly encoded 5 or 6 albums with this switch. Is there likely to be any quality problems that you know about. Ross. Mark Taylor wrote: The -q option is for internal testing only :-) -q1 enables some more the thorough scalefactor searching code that hasn't been worked on in a while. I was hoping Iwasa would put in some of his code, but it isn't done yet -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] full huffman search for every loop
Takehiro some time ago (below) added or suggested he was adding this option to LAME. Is it available? I mistakenly thought -q1 was activating it as it is so much slower. Cheers, Ross. Takehiro wrote: I agree with -h n option. So I list the some quality depending settings and some summury. Any comment welcomed. 1 about Huffman code searching I think mp3enc has 3 mode of huffman code searching. (1) the aproximated best Huffman code.(older LAME code) (2) after last loop run, perform a full huffman search(my new code) (3) huffman full search for every loops. I test implemented (3) and it is "terribly" slow :). I think it should be enables only when the highest quality setting. So I will add this in -h 0 :) 2 Analog threshold LAME's main quantization loop continues even after "over==0", to reduce the max_noise or total_noise. I think it is not needed for some circumstance. With some low quality setting, we can remove this loop. # I think this is what mp3enc calls "max outer loop" 3 subblock gain and scalefactor scale see another my mail :) including these items, quality setting will be like this. *-h 0: full Huffman search for every loops. *-h 1: *-h 2: m/s masking thresholds *-h 3: *-h 4: more accurate quantization (quantize_xrpow) *-h 5: *-h 6: full Huffman search (best_huffman_divide) *-h 7: scalefactor scale code *-h 8: analog threshold *-h 9: subblock gain code --- Takehiro TOMINAGA // may the source be with you! -- -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Bug with -q1 (win32)
I'm using new Win32 compiles from Dmitry. There appears to be a bug in LAME 3.84 CVS where it won't start encoding some WAV files (LAME -q1 file.wav). It just sits there doing nothing probably in an infinite loop. -q2 works fine. I managed to encode an entire album but for another album there are 4 tracks which will not encode. All files ripped from CD. I've stripped a half second from the beginning of one track and put it here for debugging purposes http://www.enternet.co.nz/users/ross/test.zip (57kb). Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Quality switch -q
I'm forced to be an Outlook user at work, which this was sent from. I will give myself top marks. Ross. Ingo Saitz wrote: My sister became some sort of MS Certified Professional today. I [Telsa] knew she could do it. She's the only person I know who sends me email with Outlook and yet still manages to send it in ASCII with the quoted material at the top with " " at the start of each (less than 76 char) line and her comments nicely interspersed beneath. (See, Outlook users, you can do it!) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Continuation of crippling wavs
I think your wasting your time Shawn. There have been problems in the past with LAME and other encoders which may have been expoited to make bad sounding MP3's, but as each distortion is isolated, it has also generally been worked on to overcome the distortion. So I suspect your album would become the test case to get LAME working even better. Cheers, Ross. Shawn Riley wrote: If you remember my question a while ago about crippling wavs so they sound bad at all but the highest bitrates, this is a follow-up. My band is recording its album in the near future. I know MP3 has its limitations, I thought it would be useful for the band from a business perspective if we messed with the original recorded tracks to make so-called "CD-quality" MP3ing difficult. The recorded tracks will probably consist of the following (maybe less, but no more)- 2 tracks for the kick drum (front back) 2 tracks for the snare (top bottom) 4 tracks for the toms (4 toms- one track for each) 1 track for the hi-hat 2 overhead mics (for the cymbals room resonance) 4 tracks for the guitar (2x stereo) 1 or 2 tracks for the bass guitar (1x mono or stereo) up to 4 tracks for vocals (1x stereo lead, up to 2 backups) up to 4 tracks for keyboards (2x stereo) up to 4 tracks for solo instruments (more if we get carried away hire a 96-piece orchestra :-) The album will be a mix of ballads rock songs. How do you guys suggest we do it? Note that we'd like there to have no percievable difference between the original effected sound in the studio. I decided that the MP3 encoding should be bad for the following combinations- 128kBit/sec - JStereo - 44.1kHz 112kBit/sec - JStereo - 44.1kHz 56kBit/sec - JStereo - 22.05kHz I'd like to limit the subectivity of the word, "bad", to mean that it sounds particularly nasty unfaithful to people who are normally satisfied with sound quality at those described bitrates. But I'd like it to still sound perceivably lossless for 320kBit/sec - Stereo, 'cause *I* would like to be able to make an MP3 of our stuff w/o having artifacts popping out everywhere. But that doesn't really matter quite so much 'cause I could always get a copy of the CD, mastered without the mangling. Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.80 beta
Christian Schepke wrote: What about the idea with the trial-version of LAME. AFAIK it's allowed to distribute trialversions of mp3-encoders. We could include a little routine that displays a WARNING TRIAL EXPIRED or something alike, when the 30 days are over. That is true BUT, the binary distributor can only produce trial versions with the intent of selling them. Also, there is a minimum annual figure that must be paid to FHG. I forget the amount but it was 5 or 6 digits. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] more on the winamp decoder bug
Has anyone bothered telling Nullsoft about this bug? Ross. Mark Taylor wrote: I put a web page together on the winamp decoder bug, since I've now recieved 4 independent LAME bug reports related to these pure sine wave and "sweep" test cases. www.sulaco.org/mp3/winamp/winamp.html This shows plots of the winamp and mpg123 decoded wav files, showing two errors in winamp when decoding a pure 100Hz sine wave: periodic dropout (it looks like 1 granule, about every 1 second is replaced by zeros) and some glitches at the very beginning of the decoded file. I also added links to Naoki's page and Matt's results. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] LAME Windows ACM
There has been a number of requests for an ACM. Acy Stapp had a go but had problems with the Windows ACM not supporting VBR, but the main problem was LAME was not thread safe at the time which the ACM requires. I see Mark T has made some changes in his area so maybe its time for another try. Ross. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Zia Mazhar Sent: Monday, 1 May 2000 23:31 To: [EMAIL PROTECTED] Subject: [MP3 ENCODER] MP3 Encoding Plugin Found it at last: http://ftp.winamp.com/components/P/out_mp3.exe Yes, it requires an ACM Codec installed. Is there any probabillity that LAME will release one? :-) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Various
Mathew Hendry wrote: normal stereo allowing a more "free" allocation of bandwidth between the channels? AFAIK it doesn't. I'm not sure where that idea originated. I have been under the impression for several years that Stereo (mode 0) shares bits between the channels. If one channel was more complex than the other then it would allocated more to the channel that required it. I presume this is what LAME is doing, is it not? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Various
Yes it is. The question is whether dual_channel is more restricted than that. Dual-channel is just what the name suggests. Each channel is completely independant. I don't see any advantage of using dual-channel. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] 3.80 bug
I'm using Dmitry's WIN32 compile of 3.80 dated 19 April and there is some bad noise frames being generated throughout many songs I've just encoded. I'm not entirely sure but it appears to occur in the song at the points where alot of informative errors regarding pre or post bit wastage occur. In one 20 second section I got about 6 noticeable noises. The noise sounds like a very small portion of the song was speed up. I'm using Winamp 2.5e. Is this a known problem? Fixed? Need a sample? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
Hi Matthew. Interesting analysis. Just one question. What do you mean by WinAmp's EQ sucks bigtime. They all have the same frequency response. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.80 VBR observations
Mark Taylor wrote: On Sat, 15 Apr 2000, Ross Levis wrote: If anyone is interested,VBR is now more spread over the bitrates. Here is a $ bitrate. Some -V tuning is obviously needed. I guess the better lossless co$ Did you notice any quality differences? I did some listening tests and I could not tell any difference with the song concerned. It may require a more difficult piece to determine that. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.80 VBR observations
I was using the "Russian" WIN32 compile which was given an alpha revision of "k", compiled 14 April. Ross. Robert Hegemann wrote: Hi Ross, as LAME 3.80 is the CVS version, may I ask you: which version of LAME 3.80 did you compare with LAME 3.70? Robert Ross Levis schrieb am Sam, 15 Apr 2000: If anyone is interested,VBR is now more spread over the bitrates. Here is a partial frame analysis of a song (all encoded with -h -mj ). I included -V3 analysis to obtain a closer average bitrate. Some -V tuning is obviously needed. I guess the better lossless compression is having an effect. v3.70: (-V4) 64 - 1 - 0.0% 80 - 76 - 0.6% 96 - 1106 - 9.0% 112 - 5943 - 48.6% 128 - 3348 - 27.4% 160 - 982 - 8.0% 192 - 489 - 4.0% 224 - 191 - 1.6% 256 - 76 - 0.6% 320 - 10 - 0.1% Average bitrate: 124.6 v3.80: (-V3) 64 - 18 - 0.1% 80 - 343 - 2.8% 96 - 2821 - 23.1% 112 - 2858 - 23.4% 128 - 2587 - 21.2% 160 - 2570 - 21.0% 192 - 634 - 5.2% 224 - 242 - 2.0% 256 - 106 - 0.9% 320 - 42 - 0.3% Average bitrate: 129.1 v3.80: (-V4) 64 - 58 - 0.5% 80 - 1771 - 14.5% 96 - 3709 - 30.3% 112 - 2859 - 23.4% 128 - 2075 - 17.0% 160 - 883 - 7.2% 192 - 557 - 4.6% 224 - 174 - 1.4% 256 - 89 - 0.7% 320 - 35 - 0.3% Average bitrate: 115.3 Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- e-mail: [EMAIL PROTECTED] homepage: http://linux.unixcity.de/catwalk/index.html -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Sorry for any duplicates
This damn Netscape Messenger does some strange things sometimes. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] 3.80 VBR observations
If anyone is interested,VBR is now more spread over the bitrates. Here is a partial frame analysis of a song (all encoded with -h -mj ). I included -V3 analysis to obtain a closer average bitrate. Some -V tuning is obviously needed. I guess the better lossless compression is having an effect. v3.70: (-V4) 64 - 1 - 0.0% 80 - 76 - 0.6% 96 - 1106 - 9.0% 112 - 5943 - 48.6% 128 - 3348 - 27.4% 160 - 982 - 8.0% 192 - 489 - 4.0% 224 - 191 - 1.6% 256 - 76 - 0.6% 320 - 10 - 0.1% Average bitrate: 124.6 v3.80: (-V3) 64 - 18 - 0.1% 80 - 343 - 2.8% 96 - 2821 - 23.1% 112 - 2858 - 23.4% 128 - 2587 - 21.2% 160 - 2570 - 21.0% 192 - 634 - 5.2% 224 - 242 - 2.0% 256 - 106 - 0.9% 320 - 42 - 0.3% Average bitrate: 129.1 v3.80: (-V4) 64 - 58 - 0.5% 80 - 1771 - 14.5% 96 - 3709 - 30.3% 112 - 2859 - 23.4% 128 - 2075 - 17.0% 160 - 883 - 7.2% 192 - 557 - 4.6% 224 - 174 - 1.4% 256 - 89 - 0.7% 320 - 35 - 0.3% Average bitrate: 115.3 Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] the road to next(v4.00?)
Mark has said a few times that there are several rather obvious things you could change that may increase sound quality. Could these "things" be implemented in an MP3 encoder, or would they need a completely different format? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Masking in stereo
Shawn Riley wrote: So the encoder would have a cow if it was using forced JS that happened? Mark, can you mention if LAME can turn off joint-stereo when needed even when -mj is specified. Or does it force it on for all frames? Thanks, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME/MPG123 ACM
Mark Taylor wrote: what's a Windows ACM? Audio Compression Manager driver. (VCM=Video...) It provides native support from MS-Windows OS calls to the codec. Any audio application would be able to open/play save/encoder MP3 files just as if they were PCM WAV files. The application doesn't know any difference. You can use MP3's for Windows desktop themes/sound events etc. Microsoft Media Player installs a "Decode Only" FHG MP3 ACM driver, among others. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] LAME/MPG123 ACM
Sorry, I was wrong about Nero CE2K. I had this thought some time ago. I'm not a C programmer so I can't do it myself, but, is there anyone out there who is willing to write a Windows ACM driver incorporating LAME MPG123. I know a lot of people are using FHG for the sole reason that it is the only major ACM for MP3, and they can use any WAV player to play them and any recorder to encode them. I think it would be very popular. Just a thought. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] xing vs. fhg (vbr)
IMO Xing. Ampex wrote: is xing or fhg better at vbr? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] mp3 vs. wma
there's also no good mp3 DirectMedia codec except for the discontinued FhG pro codec version 1 When you say DirectMedia, do you mean a Windows ACM driver?. If so there are newer versions of the FHG ACM released with some software packages like Nero 4.0 and Cool Edit 2000. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: highq mode
Actually you can extend a Win95/98 DOS window to 43 or 50 lines which then allows scrolling up. It is in the Properties/Screen tab. It doesn't completely help because there are more than 50 lines printed. It goes back as far as "--lowpass freq". I have the same problem. I have become rather skilled at hitting the Pause button at roughly the right time. Ross. Mark Stephens wrote: BTW, in NT you can specify a scroll back buffer for the command line window. You can also make it as many lines that can fit on the screen, so this is really only an issue for win95/98 users. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME in the PRESS
Felix von Leitner wrote: I wonder where the myth that joint stereo would somehow adversely affect quality comes from. Was it the web pages from the BladeEnc guy? I don't know. Anyway, joint stereo does not make the signal and worse, it just allows for a better bandwidth use because on most signals the bulk of the sound is equal on both channels. With joint stereo, this part is only encoded once for both channels, so this is a good thing. It was well known 2 or 3 years ago that Fraunhofers' joint-stereo (l3enc) at any bitrate sometimes produced horrible distortion in the treble when the left right channels were partially out of phase. I found it mostly encoding older 70's songs but it did crop up in modern songs ocasionally. I switched from l3enc@128 to BladeEnc@160 as soon as it was available and the results were 1000% better. BladeEnc doesn't use JS at all. These days JS is much better in all the popular encoders. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] highq mode
Don Melton wrote: --qual low equivalent to highq=9 --qual normal " " " 5 --qual high " " " 2 The idea to create secondary options may be a good way to avoid confusion. LAME is starting to take off as a quality encoder so the user base is likely to explode soon. It would be good to get this sorted out ASAP. I still favour a reversed numbered approach rather than low/normal/high etc to enable far more flexibility in the future. -V3 -b160 -B320 when it might seem more obvious to do this: --vbr 192 --min 160 -max 320 I don't think this can work. Someone that always encodes classical music, for example, would find the average bitrate is nothing like someone who always encodes rock. It would be too confusing. For your example I still prefer "--vbr 6". My thoughts are wandering too far here but: it would be possible to use your format if the resulting average was forced to be close to the selected bitrate. This would take an extra dummy encoding pass through the file to establish which -V setting to use and then encode it. I suspect this would be possible but I don't know how useful it would be. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] highq mode
Jeremy Hall wrote: ok, and so that -H is consistent with -V, make it do likewise. But as Gabriel Bouvigne argued, you are limiting best quality to the lowest number available -- 0. What do you do if a better quality mode is created? Go negative? :) Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] highq mode
I would like to voice my opinion in support for 0=low 9=high. However, reversing the numbers would make -V4 change to -V5 so the default setting will have to reflect this. Ross. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg Maxwell Sent: Wednesday, 2 February 2000 09:51 To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] highq mode On Tue, 1 Feb 2000, Jeremy Hall wrote: but then you're in conflict with VBR. VBR should be changed. It makes more sence for big numbers to denote bigger bitrate in VBR. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] some stupid questions just for your pleasure ^_^
Cavallo de Cavallis wrote: Mmm interesting, probably coz more guys are workin patchin and improving it. Yes but Tord is also not altering BladeEnc for quality -- only speed. He makes sure that every update produces exactly the same MP3 file. and looking for somethin near 160 which settings are best ? -v is equivalent to -V4, lower numbers represent bigger/better, so try replacing -v with -V3 or -V2 (note the case). Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] To use VBR or not not use?
I use CDex including Lame 3.58, BUT only at 320 bitrate, to get the best quality. Which are the right options ? VBR=0? stereo mode ? .. Best quality is PCM at ~1400kb/s :) . Using 320kb/s which is only 4:1 compression, you may as well use ADPCM format which takes almost zero time to encode and is built-in to most operating systems. Tell me, if there was a 640kb/s would you use it? MP2 produces argueably better sound quality than MP3 over 256kb/s. To answer your question, CBR at 320kb/s would produce the best quality you can from MP3. VBR=0 theoretically should produce the same result with a smaller filesize but due to flaws in the psychoacoustic model, the encoder may select a lower than ideal bitrate in some circumstances. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Full huffman search, how?
It is automatically activated with -h. Ross. -Original Message- Nils Faerber Hi! Silly question since I obviously missed the posting: I read that lame now can use full huffman search. But which option toggles it? Or is it default now? Thanks! CU nils -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Disabling lowpass? WAIT!
Mark Taylor wrote: even if filter options are specified, they will be ignored if -k is also used. Wait a minute. I want to disable all filters except a lowpass at 16 khz for music on my radio station. Can you please enable the high/low pass filters if specified. Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME beta versions
Hi Ivo. I am also not part of the development team but I am interested in the progress, mostly in VBR. The beta versions are generally bug free. I have not found any versions that have introduced any noticeable problems and I can recommend using the latest one (3.60) which has had a large improvement in VBR quality. There have been some substantial gains in sound quality speed since 3.50. From what I gather, the next release (3.61) will provide a substantial increase in the speed of VBR encoding so I am looking forward to that. If you are using VBR then the following switches are manditory (IMO): -h -V5 -b32 -B320 -k --lowpass 24 I'm not sure if -k is necessary anymore but will do no harm. Maybe a developer can comment on that. The lowpass switch is really a requirement, otherwise the high frequencies start reducing above 13khz which is not acceptable (IMO). I seriously think this filter should be removed or altered to not affect any frequencies below 16khz. Cheers, Ross. Ivo van Heel wrote: This is the first time I actually post to this maillinglist and I hope this question is not out of place. I can not be called an MP3 codec expert, nor an expert on the human hearing capabilities and sound technique in general. I am, however, an MP3 and music enthoussiast, in every sense of these words' meaning. My question concerns LAME 3.51 and the new beta versions. Currently, I am using the stabe release LAME 3.51. Reading this maillinglist, I've found it very interesting to read through all the discussion concerning quality improvements and such. Much of these subjects are expirimental, I've - rightfully I hope - noticed. So I'm a bit wary about using newer beta versions. The actual question I'd like to see answered is: how stable are these newer beta versions of LAME in respect to quality? Is the produced mp3 of higher quality in general than those produced with version 3.51? How big is the chance of screwing up a WAV with beta versions? Ivo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] more loops...
Iwasa Kazmi wrote: It makes slow 10%-20%. And the improvement of sound quality is not so large. But some sources (ex. apploud.wav) will be good results. I would suggest adding the code because as I have previously mentioned, it may be a small increase in sound quality but with many such improvements, we should end up with the best sound quality encoder around. If speed is an issue then let it be added only to the -h option if possible. Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME beta versions
Sound quality is more important to me as well, and VBR should provide better sound quality for the same filesize. I have also used the Xing encoder and it is well known that it obtains it's speed by taking shortcuts which affect sound quality. Each sample in music differs in complexity and so the more complex frames will have a shortage of bits and higher distortion with CBR, whereas VBR will simply increase the bitrate to accommodate the required bits. I don't care if an obsure MP3 player doesn't support VBR. I would think all "current" players do. The -V5 setting I gave you will provide a similar filesize to Xing's VBR Normal setting (lame v3.60). Use lower -V settings to increase filesize and maybe sound quality. Cheers, Ross. Ivo van Heel wrote: I have always encoded with CBR. I don't know, something makes me wary of using VBR, maybe it's the sound quality I got using VBR with the Xing codec, or maybe I'm just crazy. I'm just afraid it will reduce sound quality (which is most important to me, more so than file size; still I want the best quality-size trade-off) or that VBR MP3's will not play on some obscure MP3 player. Please, prove me wrong. :) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] cwlimit?
Can someone please explain this option please. Thanks, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Windows Binaries
Mathew Hendry wrote: Can you name a compiler which will do this on normal code, i.e. without the use of MMX/3DNow-specific functions and macros or [inline] assembler? I'm afraid I can't. Normally special-case code will be required to take advantage of these enhanced instruction sets. If that is the only option then maybe specialised code could be written into LAME to support MMX. I think most computers these days are running MMX processors. I'm not sure what the actual speed improvement would be and maybe it's not worth the effort. However, there are some customised versions of LAME around. Take a look atthe GOGO-no-coda, which I believe has MMX and 3DNow! enhancements, amongst other things. Yes, however, I prefer some of the later ammendments of LAME. Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] filter options
John Hayward-Warburton wrote: It is true that some FM stations (in the UK at least) put filters in below 30Hz to allow in-band switching tones to be used between studios. Not that we use a filter here but I am aware that a lot of stations in the USA and elsewhere use a highpass filter which I thought was around 50hz (but maybe its 30hz) to allow more energy in the more audible freqs and therefore produce a louder sound. "Louder the better" is usually the motto. Maybe the highpass option should be removed altogether from the FM preset. I hope this is not too much of an imposition, but has anyone documented the various `-X n' options? I'm getting better results on choral music with -X 5 while some orchestral music sounds better with -X 4. The existing documentation is *very* helpful in other aspects, though. What does the -X parameter do exactly? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] -X preferences
Thanks for the info Robert. Am I right in thinking -X0 is the default? Is there anyone testing the different -X settings on different music types. Maybe the results of tests should be published somewhere for comparison? John Hayward-Warburton has mentioned his preferences with -X4 5 in choral music. Maybe you could try the new -X6 option John. Ross. Robert Hegemann wrote: What does the -X parameter do exactly? When LAME searches for a "good" quantization, it has to compare the actual one with the best one found so far. The function quant_compare says which one is better, the best so far or the actual. Now the -X parameter selects between different approaches to make this decision: -X0 the actual is better if it has less distorted scalefactor bands, or if it's equal to the best so far and the sum of noise over the thresholds is less than the best so far -X1 the actual is better if the maximum noise over all scalefactor bands is less than the best so far -X2 the actual is better if the total sum of noise is lower than the best so far -X3 the actual is better if the total sum of noise is lower than the best so far and the maximum noise over all scalefactor bands is less than the best so far plus 2db. -X4 this is a bit complicated, I think Greg Maxwell should explain this ;) -X5 the actual is better if the sum of noise over the thresholds is less than the best so far or if they are equal and the total sum of noise is lower than the best so far -X6 the actual is better if the sum of noise over the thresholds is less than the best so far or if they are equal and if the maximum noise over all scalefactor bands is less than the best so far or if they are equal and the total sum of noise is less or equal the best so far All these are EXPERIMENTAL and may disappear sooner or later. Maybe we find the one and only criterion someday. I hope it's getting a bit clearer to you. For the details take a look at quantice.c, search for experimentalX. Robert PS: -X6 is new, I just checked it in -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Change -V default to 6?
(LAME v3.58) -V6 is producing very similar average bitrates to Xings normal setting -- roughly 128kb/s. -V5 is averaging around 140kb/s. The default -V4 is getting up towards 160kb/s which is producing somewhat larger files. I think the default should be 6 (or at least 5) to be more consistent with the standard 128kb/s filesizes which most of the international mp3 community are using. Just my opinion. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] filter options
Hi Robert. Hopefully someone else can help with the Win32 compile - please :) I think Marks suggestion of using a width option may be less confusing and easier to use. As far as radio is concerned, the 2 main presets would be something like this: 1. Music/commercials: FM50 - 15000 hz, stereo: --lowpass 15000 --lowpass_width 0 (sharp cut-off) -m j -b 128 Not sure whether a highpass at 50hz would be beneficial or not. 2. High quality voice (interviews etc). I'm not sure what the best settings for this would be. I haven't analysed voice frequencies so I'm guessing at the following: HQvoice 200 - 1 hz, mono: --lowpass 1 --highpass 200 -m m -b 64 Support for variable bit-rate should be added to the presets as well. If -v is specified, an equivalent -V setting should be defaulted. I presume -V4 could be used for both of these. The -b settings would have to be increased or removed. Cheers, Ross. Robert Hegemann wrote: Hi Ross, I have no Windows, so I can't help you with a Win32 version. But I want to start a collection, that could become something like presets for Lame: phone 300 - 3400 hz, mono: --highpass_l 300 --lowpass_h 3400 --noshort(preechoes are a minor issue) --resample 16(8 would be better, needs MPEG2.5) -m m -b 16 (8 is a litle bit to low :( CD 2 - 2 hz, stereo: --lowpass_h 2 --resample 44.1 -m s -b 192 And as you are working for a radio station, you could probably extend the list for different radio types, studio standards, etc. Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] New switch wanted for 16khz filter (-K?)
Thanks for adding it to the list Mark. I think your idea for low highpass options would work very well. It would also fix the VBR problem I posted. I can see it would benefit sound quality considerably for FM radio people who would want a sharp cut-off at 15khz. I am a programmer but in a 4GL database language so I can't help directly with Lame development. However, I don't understand the need for 2 variables for the filter. Why do you need to start applying the filter earlier than the cut-off frequency? I would prefer a sharp cut-off. If required, we may need another option to specify this fade-in filtering. Cheers, Ross. I added this to the todo list. I think it would be best to have a --lowpass freq and --highpass freq options, and remove the -k and sfb21 switches alltogether. The default lowpass frequency would then depend on the bitrate and sampling rate. But in the mean time, it is easy to add this: for example, in lame.c around line 724, if you hard code lowpass1=.50 lowpass2=.65 it will start applying the filter at 22*lowpass1 kHz, with all frequencies above 22*lowpass2 kHz removed. (22 is assuming 44kHz sampling frequency.) Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] L.A.M.E. Banner?
Banner looks good Chuck. I don't know about the Intel look-alike logo however. Some people might think Lame only runs on Intel processors. Just my opinion. Cheers, Ross. Chuck Zenkus wrote: Name: lame_banner.jpg lame_banner.jpgType: JPEG Image (image/jpeg) Encoding: base64 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] VBR not as variable as Xing
Hi all. I'm new to the list. I have been using Xing's VBR up to now but I am hoping to find Lame produces better VBR quality - but I'm not so sure. I may be wrong but it appears Lame's VBR is not as variable when it comes to choosing different bit-rates for each frame. I base this on the Winamp display but also under Xing VBR (normal) I have often seen average rates ranging from 90 to 150kb/s depending on the complexity of the music. I don't see anything like this type of range with Lame. Can anyone comment on this. Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Re: VBR not as variable as Xing
I should have added that I am using the switches -b 32 -B 320 Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: VBR not as variable as Xing
Unfortunately I'm running Windows rather than Linux. I will take that plunge once it is more configuration user-friendly. The -V4 switch in v3.57 (without -v which doesn't appear to be required). I noticed that prior Lame versions required -V5 to average close to 128kb/s whereas -V4 is now closer. I notice also that silence appears to be encoding at 64kb/s rather than 32 as specified, whereas Xing VBR (normal) encodes it at 48kb/s. The major factor which concerned me was a frequency analysis I performed on a song encoded with -V5 (v3.57) which averaged around 112kb/s. It did not show anything over 16khz. I realise that without the -k option that bitrates below 128 are cut at 16khz but surely with VBR there should be higher bit-rates and so higher freqencies. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: VBR not as variable as Xing
Ampex wrote: how does xing vbr compare to lame, in quality? I don't have the equipment to do high quality listening tests but other tests have shown Lame to be better than the Xing encoder. I found Xing better than Fhg for joint-stereo distortion. Greg Maxwell wrote: If the cutoff is turned off and on within the file it produces an audible effect. Therefor, the cutoff is selectd based on the -Vn setting and stays throught the entire file. I think that -V5 and larger have the cutoff. You can always disable the cutoff completely with -k. Thanks for that info Greg. It was confusing me and I didn't see that documented anywhere. I will open a new thread now on this cut-off issue. Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] New switch wanted for 16khz filter (-K?)
Dear programmers :) I use MP3 for encoding borrowed CD's for a legal low-power FM radio station in New Zealand. To save money I am not using a frequency limiter/sound compressor and I'm allowed to use 16khz rather than the usual 15khz cut-off. I'm using Winamp plug-ins for the compression and relying on the Xing encoder switch to filter out all frequencies over 16khz. I would rather use a better encoder and Lame is heading to be the best. Could one of you kind programmers please consider a new switch (say -K or -k-) to permanently turn on the existing low-pass filter. As I said, Xing has this option, and for FM radio which doesn't need the higher frequencies, it would leave more bandwidth for better quality encoding. Greg tells me that using VBR with -V5 or higher setting turns on the filter but I would prefer to use -V4. Thanks for your consideration, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
