FrontEnd->Lame using CDDB2

Posted by: jpski

FrontEnd->Lame using CDDB2 - 17/10/2000 16:51

I'm looking to set up a new system to rip my CDs to MP3s. I have been using AudioCatalyst since it has been out. Recently, I have started to notice the artifacts in my music due to the Xing encoder... the most noticable of which is a 'flutter' in voices when deep bases playing at the same time.

Here is what I want:
Front End:
-CDDB2 support (for full CD information).
-ID3 tag support (using CDDB2 information).
-Artist/Album/Artist - Album [track] title.mp3 naming.
-Support for: Command-line back end (LAME encoder).
Ripper: Support for Plextor drives.
Encoder: LAME

Optimally, I want to insert a CD, hit [GO], wait... Have the entire CD ripped/encoded/named/stored(in correct dir)/ID3-tagged.

Has anyone set up such a system? Any suggestions?

Mk2/40GB/Blue
Posted by: tfabris

Re: FrontEnd->Lame using CDDB2 - 17/10/2000 17:17

As I understand it, AudioGrabber is the same ripper/front-end as AudioCatalyst, the difference is that it doesn't come bundled with the Xing encoder, instead you can use other encoders such as LAME. Perhaps it even comes bundled with the LAME encoder? I'm not sure.

So it sounds like AudioGrabber is your answer.

___________
Tony Fabris
Posted by: jpski

Re: FrontEnd->Lame using CDDB2 - 17/10/2000 17:22

I haven't been able to get a reponse from audiograbber.com today so I can't confirm this, but I don't think Audiograbber uses CDDB2 or ID3V2 tags.

Mk2/40GB/Blue
Posted by: borislav

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 01:23

Optimally, I want to insert a CD, hit [GO], wait... Have the entire CD ripped/encoded/named/stored(in correct dir)/ID3-tagged.

You need to do at least one step manually - correct all the typos in the CDDB...

Borislav

Posted by: peter

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 02:49

Here is what I want:
Front End:
-CDDB2 support (for full CD information).
-ID3 tag support (using CDDB2 information).
-Artist/Album/Artist - Album [track] title.mp3 naming.
-Support for: Command-line back end (LAME encoder).
Ripper: Support for Plextor drives.
Encoder: LAME


On Windows, right? Exact Audio Copy does all that, except that I don't know whether it uses CDDB1 or CDDB2. It grokked all the CDs I fed it, anyway.

Peter


Posted by: Roger

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 03:11

I'd like the ability to rip/encode all the music, then come back and do all the CDDB jobs in a batch. I'm on dialup at home, see...


Roger - not necessarily speaking for empeg
Posted by: schofiel

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 05:18

I must admit I have also been using AC since I don't know how long - it was OK to use, but I admit as I got more experienced with MP3s I have gradually become unsatisfied with the encoder.

I saw a post yesterday here regarding AudioGrabber, so I went and got it - it's the same UI as AC (they licensed it, I hear) and allows you to choose which encoder you use. I bought it immediately since I like the AC interface, and this has been subtlely improved. I also pulled down LAME in DLL form and started ripping and encoding with it today. It has worked immediately with my Plextor through ASPI, with no observed problems yet.

Overall impression is that it encodes a little more slowly than the XING encoder, but seems to produce smaller VBR files. The stereo seperation has improved as well, which is a big bonus. Clarity seems to have improved slightly, but this is subjective. I am as yet not wholly sure what ID3 tag support it has built-in (I have only really started with it today).

Given that Real have decided to EOL AC, this looks to be the most immediate replacement, for very low cost, and has given me a direct improvement. It also allows for experimentation with different encoders, so - overall - I am happy with the change.

One of the few remaining Mk1 owners... #00015
Posted by: Terminator

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 07:12

You noted that lame produces smaller vbr files than AC. How are you pulling that off? My settings are set to vbr 3, high quality, js.

Sean

Empeg 12 gig green 080000078
Posted by: DiSSiDENT

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 08:01

MusicMatch can do all of that. It rips an entire cd digitally really fast and encodes them, It also does all the tags and will auto find the name of the tracks and info etc from a data base. You dont have to do anything really.

Im not 100% that all the tags are filled out, but I know it does get the names for you and puts it in any format you want before ripping.

www.musicmatch.com

Posted by: EngelenH

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 09:06

Had music match ... dropped it, ripping CD's took for ever on my system. I would have dug into it to find out why but then I also found out it works really bad with the firewalls and proxies at work (i.e. no cddb connectivity). That kind of discouraged me. Mind you I did not dig in because the overal look of Music Match imho (very subjective) was way to confusing and annoying. Yesterday I downloaded Audiograbber from http://www.audiograbber.com-us.net (just checked it and it is up and running perfectly by the way, but note that it is NOT audiograbber.com like someone in the thread said. Audiograbber.com does not exist.) and purchased it (hell only 25 bucks) immediatly. It works like a charm for me and on my system got (with no tweaking from me) about 3.6 x normal speed encoding. Compared to MusicMatch who got less then 1.0 x speed. These numbers are a little slow (I think others here prolly get far more) because I use a Laptop with a laptop-DVD and not a normal size CD-drive. More importantly CDDB works both at work and home (both NAT environments and one having firewalls and proxies too). The lame encoder seems to be working nicely but as some said Audiograbber is not picky about what encoder to use. Even external programs can be used (as opposed to the 'classic' DLL's) ...

Overall, this program is neat, has plenty of options to tweak your ripping but runs happily out of the box (so to speak) on my setup which is more then I can say for others. I like the fact that it does not DEMAND intermediate wav files, finally a ripper that makes use of the fact that I have 256 Mb ram.

I also used AltoMP3 maker, not bad, works fine too, but Audiograbber felt even better.

Cheers,
Hans


Mk2 - Blue - 080000431
Posted by: Jazzwire

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 09:12

I get about 6X encoding via Musicmatch 5 on a celery 450 with an Ultraplex drive.
Lame is quite a bit slower, but I use it on albums I really like... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)
Posted by: Terminator

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 10:57

What is CDDB2? Ive never seen it mentioned before. I went to CDDB.com, which is now called gracenote, and didn't see any info on CDDB2.

Sean

Empeg 12 gig green 080000078
Posted by: Terminator

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 10:59

Doh. Just found it.

Empeg 12 gig green 080000078
Posted by: tfabris

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 11:35

You noted that lame produces smaller vbr files than AC.

In the documentation of the command-line version of LAME (well the last one I downloaded), they said this:

Note: VBR is currently under heavy development. Right now it can often result in too much compression. I would recommend using VBR with a minimum bitrate of 112kbs. This will let LAME increase the bitrate for difficult-to-encode frames, but prevent LAME from being too aggressive for simple frames.

So maybe the reason that LAME is producing smaller files for some people is that they don't set a bitrate floor and it's compressing the simpler frames too much. When I use LAME, I follow the advice of this text blurb and set a minimum bitrate of 112. This actually causes it to produce slightly larger files, and I'm no longer getting the most "bang-for-the-buck" out of the VBR file format. Still, I am impressed with the quality of the LAME encoder although I haven't done enough testing to truly decide if it's better than Xing for the high-quality files.

___________
Tony Fabris
Posted by: Terminator

Re: FrontEnd->Lame using CDDB2 - 18/10/2000 11:57

I think in the last few versions, lame has been using the old vbr by default. Ive watched the little histogram of bitrates as encoding is going on, and it doesn't seem to have a problem with getting too aggressive.

Sean

Empeg 12 gig green 080000078
Posted by: PaulWay

Re: Bulk Tag-fetch online - 18/10/2000 15:21

I know CDCopy used to have the feature of remembering the CD's ID and then batching the CDDB query for multiple CDs. This required you to feed it all the CDs you were going to rip before you logged on, then do the update online, and then you could rip them offline. The feeding is pretty much just inserting the CD, waiting for it to recognise the new CD, and then ejecting it, from memory.

I think Exact Audio Copy does this but I'm not sure. I'm spoilt now I have cable.

Save the whales. Feed the hungry. Free the mallocs.
Posted by: Squid2k1

Re: FrontEnd->Lame using CDDB2 - 19/10/2000 04:05

In the documentation of the command-line version of LAME (well the last one I downloaded), they said this
Where did u download this from? I never seem to be able to find a compiled version of the exe or the dll.

Thanks!

Posted by: schofiel

Re: FrontEnd->Lame using CDDB2 - 19/10/2000 04:47

Ooops! Sorry - you are right. A slight slip of the typing finger - slightly larger files.

One of the few remaining Mk1 owners... #00015
Posted by: Verteggio

Re: FrontEnd->Lame using CDDB2 - 19/10/2000 07:06

Try http://www.chat.ru/~dkutsanov/~index.htm

Always has the latest version of the LAME.EXE, as well as the source code and the .dll files to be used in programs for internal encoding.

Posted by: TommyE

Re: FrontEnd->Lame using CDDB2 - 19/10/2000 10:27

10-11x on UltraPlex40x,PIII 750MHz 256RAM, MM6.

I think MM6 beats the rest.

TommyE

Posted by: Roger

Re: FrontEnd->Lame using CDDB2 - 19/10/2000 11:26

8-17x on UltraPlex40x, P2/400, 128Mb RAM, AudioCatalyst.

Unfortunately, the P2 is dead, so when the last component turns up (I'm still waiting for a 256Mb DIMM), I'll try it again with my shiny new AMD T900.



Roger - not necessarily speaking for empeg
Posted by: Verteggio

Re: FrontEnd->Lame using CDDB2 - 20/10/2000 08:38

I had a thought about this yesterday as I was ripping a bunch of CD's. Most programs (well, the decent ones) will pull the information from CDDB, and then store it in a file called CDPLAYER.INI . This file is what the default Windows CD player uses when it pulls the full track information, so that it does not have to do a query on the internet everytime you put a cd in. Note, though, the actual program doesn't have to be installed for the file to exist.

SO -- the reason I bring this up is that you could put in each CD systematically, let it find the CDDB information (which it will then write to the CDPLAYER.INI file), eject the disc, insert the next one, and repeat; all done while connected to the internet. Then, later on when you want to start doing the actual ripping, you don't have to be connected to the internet as it will pull the information from the CDPLAYER.INI file.

Basically what you want to do, however in reverse.....

--verteggio

Posted by: jhr

Re: FrontEnd->Lame using CDDB2 - 20/10/2000 09:00

Then, later on when you want to start doing the actual ripping, you don't have to be connected to the internet as it will pull the information from the CDPLAYER.INI file

To my experience there is a problem with CDPLAYER.INI in that the file is limited in size. At som point no additional cd information pulled from the CDDB database will be stored. At least that was the problem I ran into when previously using Audiograbber.
A better bet would be to use a ripping application that maintains its own database, like Exact Audio Copy.

/jan

Mark 1 #317 - 20GB blue
Mark 2 #080000217 - 18 GB amber
Posted by: Terminator

Re: FrontEnd->Lame using CDDB2 - 21/10/2000 17:13

8-20x on PlexWriter 8432a, AMD D600 OCed to 900, 128Mb RAM, audiocatalyst

How did you kill your p2?

Empeg 12 gig green 080000078
Posted by: EngelenH

Re: FrontEnd->Lame using CDDB2 - 22/10/2000 01:40

Seeing everybody list his speeds here reminded me of a site from Erik Deppe. A Belgian dude who has spent a lot of time writing some utilities and reports on CD/DVD/.. speeds including DAE speeds ... Might be worthwile for some people here who are thinking of buying a CD/DVD or whatever drive an wish to compare it's stats. Erik's page is ==> HERE <==. If you have ANYTHING to do with CD's DVD's or CD-R(W)'s you defenitly have to pay this site a visit.

Cheers,
Hans


Mk2 - Blue - 080000431