Cutting lame encoding time in half with --vbr-new

Hey,

I was waiting for LAME to finish my Orbital discs and started flipping through the online manual when I came across the --new-vbr setting:

Invokes the newest VBR algorithm. During the development of version 3.90, considerable tuning was done on this algorithm, and it is now considered to be on par with the original --vbr-old.
It has the added advantage of being very fast (over twice as fast as --vbr-old).

I've been using this with the --alt-preset standard for a bunch of CD's and it sounds really good, and it's *super* fast. Has anyone else tried this? I'm using the lame 3.91 btw.

later,
ajay

How fast is super fast? Express it as a factor of the orginal playtime.

Bruno

It cuts the encoding time in half.

Ya. I got that much. Half compared to what?

Just tell us what processor you're running and the reported speed factor from the LAME console output for a sample track. You might as well include details for any other options if you're using them.

I know how long it takes me to do my encodes, but someone who isn't currently using lame will find your message meaningless.

Anyway, we're not pulling teeth are we? If it's too much trouble, then that's ok too. I don't plan to re-rip my collection, but I do like to stay on top of interesting news.

Bruno

This might be a silly question but is there any way to use that with EAC? If so how? I'm running a dual Athlon XP 1600 rig and between EAC and Lame it takes about 2 minutes per song... 4 minutes if your running two instances at once.... I'd like to cut that down... as I could rip a whole album with xing in about 5 min (yeah sound quality sucked but it was fast, I realize the error of my ways and have seen the light)...

Also what are the pros and cons of using a variable bit rate?

Interesting. I can rip a whole album with LAME set to alt-preset standard in 5 minutes, including DAE, and I only have a single Athlon XP rig (1600+ oc'd to 1537Mhz)... What CD-ROM are you using for DAE?

I still don't see why everyone is complaining about Xing. At its highest VBR bitrate, I can't tell the difference between a Xing-encoded file and a LAME-encoded file.

i second that motion.. neither can i. and it is a lot less to much with lol.

Encoding (not the DAE part, *just* the encoding) time for me on an AMD duron 700 is cut in half. I only did a couple of tests but on average if a song showed an ETA of 5 minutes, after I added the --vbr-new switch then the ETA was around 2 and a half minutes. The switches that I'm using:

--alt-preset standard
--disptime 20 (delay between display updates)
--nohist (disable histogram display)

Running these with EAC is not a silly question, lopan, because that's how I do it! Just go to the EAC->Compression options menu and select the "External Compression" tab. You should already see the lame options in the "Additional command line options" box. Right before the "%s" add in "--vbr-new" and you're all set.

There'a a FAQ section talking about encoding and the pros of VBR.

And finally, ClownBurner, I'm using a wicked crappy IDE CDROM drive for my DAE and it only goes about 3.5X, my older Plextor 12/20 just bit the dust and I need to get a replacement.

later,
ajay

On my Celeron 935 (overclocked) running in WinXP, I could encode at about 2x with LAME 3.89. With LAME 3.91 it's about 4x. With 3.89 I was using the individual parameters recommended by www.r3mix.net. With 3.91 I use the --r3mix setting which uses the faster VBR algorithm.

I just upgraded my HTPC to a P4 1.6A running at 2.1 Ghz. I've got to try some encoding on that machine. I bet it'll scream.

-Dylan

I'm actually happy to hear the xing praise... I used it for years. After reading a few different post on encoding and visiting a few sites I was conviced lame was the be all end all encoder! I do like xing, I don't like it's id3 capabilities though. I'll keep using lame for now.

As for my speed, it's gotta be my CD Roms, 1gig of DDR, 2 XP 1600's with a 4 channel Ultra 2 SCSI raid with 4 drives striped at 0 accross all 4 channels.... I'm thinkin definately has to be the CD Roms, I have a 12x 8x 40x Sony Spressa (not sure on the specs but I know it's a 12x cdr) and a Pioneer slot feed DVD (old).... The Pioneer is actually faster than the Sony.

You need to read up on DAE (digital audio extraction). Just because a drive can "read" at 40X doesn't mean it can do DAE anywhere near that rate. My current crappy CDROM drive is 52X but the DAE is only around 3.3X. A good drive to get is the TDK Velo-CD and of course, any Plextor brands. My 12/20X plextor actually got up to 8-10X DAE speeds which was impressive at the time (a few years ago).

later,
ajay

well when I configure EAC for speed... I get anywhere from 1x to 6x... most of the time in between there. Sometimes I have to reconfigure the drive through the setup wizard just to get it to go above 1x... which is weird.. whenever I configure the drive i'll hit 6x then after about 7 CD's I have to reconfigure it again. Ever had that happen?

I used Xing for a while (some time ago though). At 'ordinary' bitrates of 128k or so there was a definite loss of the higher frequencies, it left my mp3's sounding very dull. I can't speak for more recent copies as I dropped back to AudioGrabber & Lame and have been pretty happy. I only rip occassionally so I'm not a speed freak.

-Zeke

This is my primary complaint about encoder comparisons-- they're all compared at 128.

This kind of comparison is useless to me because I can hear artifacts from ANY encoder at 128 if given the right material and the right listening conditions. Once you push it up to past 160, or use a decent VBR setting, I can't tell one encoder from the next.

Since I can remember, Xing has been famous for a really nasty lowpass at around 16 KHz. If you can't hear the difference then it's no big deal, or they might have changed the lowpass, or given it a configurable cutoff... But I remember that was one of the big knocks against Xing in the past, no matter what bitrate was used.

Every encoder has a lowpass filter, not just Xing.

LAME has an option to disable its lowpass filter, but it's on by default.

"I'm running a dual Athlon XP 1600 rig and between EAC and Lame it takes about 2 minutes per song"

Mmm... with my old Celeron 300@450 EAC takes about two minutes per song and the same time is for Lame...

BTW I have a Pioneer DVD rom 16x40x

Every encoder has a lowpass filter, not just Xing.

Duh.

I am well aware that all encoders have a lowpass due to high frequencies being more expensive per bit to reproduce. What I said was that Xing's is particularly famous for being set too low, so that the lowpass effect was very audible, and it wasn't configurable. You don't have to be a dog to be able to hear a 16 Khz signal. As I said, Xing may have taken corrective measures, but that was always a common complaint of Xing users.

Ah, no wonder, then. I activated the "high frequency mode" feature in AudioCatalyst when I used it. From the help file:

"High Frequency Mode when selected, enables encoding of high frequencies (up to 20kHz), for CBR bitrates 112k and VBR settings of Low/Normal and above. Note: Only a small percentage of users have both hardware that can clearly reproduce high frequency sounds and exceptional hearing to distinguish those high frequencies from lower frequencies within the music."

Okay, I will revise my statement. When I deactivate the Xing low pass filter, and I encode at a decent bit rate, I can't tell the difference between LAME and Xing.

And yes, I agree that you don't have to be a dog to hear 16k, and that this helpfile entry is misleading.

Yah, I wasn't disputing your claim that Xing was doing a good job, I was just trying to shed some light on Xing's checkered past. Back in my EFnet #mpeg3 days they would damn near lynch anyone who was distributing MP3's encoded with Xing. It was a very perceivable difference in quality.

lopan, I never had a problem with having to reconfigure EAC. You should set it to make accurate copies though so the RIPs are better. Just a suggestion because I've had CDs that would play fine in a CDplayer but when I ripped them on "Burst Mode" they would have little skips in them.

later,
ajay

You should set it to make accurate copies though so the RIPs are better. Just a suggestion because I've had CDs that would play fine in a CDplayer but when I ripped them on "Burst Mode" they would have little skips in them.

Hear, hear. You only rip and encode it once, but you listen to it lots of times. It makes sense to ensure a perfect rip (cdparanoia -z, EAC "Secure mode" if available, "Paranoid mode" if not), even if it takes ten times longer.

Peter

ok, a couple of questions. First of all, I'm using the latest version of EAC and lame 3.91. Could someone assume I'm an idiot (a safe assumption, BTW) and tell me exactly what settings I should use to get the best quality VBR files? Also, I have a Plextor 8/4/32 drive. Do I need to do anything to *it* to make extraction easier/better?

Finally, I'm running a Celeron 533 with 512 mb RAM. If I have it rip and encode a cd in the same session, it does it in about real time. i.e. if a cd is an hour long, it takes about that to do both steps. Is that normal? I'm upgrading to a 1 gig/133 next week. Should that make a big difference?

Even if it takes 10 times longer??? I know... but I've got close to 500 cd's I'm encoding here... already encoded all of them a long time ago (stupidly at 128)... So this is a painful process....

And thanks dylan... I used that --r3mix setting... EAC still takes a while but once it's pulled down in a wav format and lame kicks in, I can do a 3 minute song in around 25 seconds...

If you're using the latest EAC/lame then go through the configuration wizard and select when it asks you about which style of DAE you want, select "I perfer to have accurate results" vs. "only speed is important" option.

Then let it install and configure LAME for you as well. And make sure the "use recommended settings (from r3mix forum)" is selected. The default EAC/LAME combo works great.

Oh yeah, go to File->configuration wizard to start the ball rollin'

later,
ajay

Yeah thats what I go through everytime my cd roms slows down... I don't seem to be getting those problems anymore though, I'm not burning as much maybe that has something to do with it? Can't believe I've already gone through almost 40 gigs, I was burning album after album, one after another thats when I was having those issues. However now I'm running out of drive space on my pc and slowed the process down a bit. Went to pricewatch.com and looking at drives right now, gotta have a place ta back all this up ya know. I'll start using the accurate settings once I get it.

So no one is going with the %s %d --alt-preset standard?

the "recommended settings" in EAC uses the --alt-preset standard setting instead of --r3mix.

later,
ajay

I thought that the r3mix settings had become obsolete last month, replaced by --alt-preset, supported since Lame 3.91

I thought it was --alt-preset standard %s %d..

In reply to:

---

I thought that the r3mix settings had become obsolete last month, replaced by --alt-preset, supported since Lame 3.91

---

in lame 3.91, the "alt-preset" stuff got a lot of improvements and is now considered to be the best in terms of quality and size.

while --r3mix is just a shortcut for several different switches, --alt-preset actually changes the way the internals work.

Read the Changelog for LAME and you'll find a lot of useful info about --alt-preset

later,
ajay

later,
ajay

I ran through the EAC configuration wizard, to see how it's choices would compare with my manual setting of Lame parsing with command line options --alt-preset standard -b32. When I looked at the compression settings after picking the r3mix recommended settings in the wizard, I saw that it uses these "Additional command line options:"

%l--alt-preset 128%l%h--alt-preset standard%h %s %d

and it has selected "User Defined Encoder", with the path to my lame.exe.

Can someone point me to an FAQ that explains what the %l...%l, %h...%h, %s, and %d do?

Thanks, I wasn't aware of --alt-preset. I'll give it a shot.

-Dylan