I'm about to go back and re-rip all of my CDs, my current database is such a mess. Not sure if this has been mentioned before, but is there currently a loss-less compression for audio tracks available? I'd like to rip these just once more, put them in a loss-less compression, then do mp3, ogg, wma, or whatever from that...

anyone know of such a beast?

g

The lossless compression schemes available at this time only buy you about 50%, in terms of storage space, over raw WAV.

If I were you, I would calculate the amount of required space for just storing it all as WAV files. Then I would see if it'd even do you any good to save it as one of the lossless schemes. If 50% is not enough, then it's a moot point.

Besides, storing it as WAV or lossless doesn't really buy you any time or any "loss of hassle" when you want to re-encode. In fact, it's probably more time and hassle than it would be if you just left everything on the original CDs...

A good survey exists at the FLAC Comparison page, FLAC being one such encoder.

So you think that encoding a bunch of files that are sitting in a directory on your computer is no less hassle than swapping hundreds of CDs in and out of your CD-ROM drive?

I respectfully disagree. When reripping, you have to swap a new CD in every few minutes, requiring that you sit in front of your computer the whole time. Reencoding those losslessly encoded files can be done by setting up a batch job and letting it run for days on end, if need be, without any further intervention.

I agree with Tony that it can be a lot of hassle, unless you can convert direct from losless compression to whatever lossy compression format. But to answer your question, is there such a beast, well yes, go to:

http://flac.sourceforge.net

Flac seems to be the flavour-of-the-month and pretty easy to use.

[edited] Oh well, so I was beaten to it by 2 min...

So you think that encoding a bunch of files that are sitting in a directory on your computer is no less hassle than swapping hundreds of CDs in and out of your CD-ROM drive?

If you depend solely on the CDDB to tag the songs, yes.

Note that this takes into account the problems people have been reporting in getting their WAV files to encode properly (without a "pop" at the end) when appending tag data to a file other than an MP3 file.

And let me just re-defend my original statement: It might be a moot point for him if 50% compression doesn't solve his storage problem.

If he doesn't have enough hard disk space to store these lossless files permanently, then he'll have to offload them onto tape or CD-R. And then his re-encoding pass will involve the hassle of restoring all of these files. If they happen to be on CD-R, the restoration will be nearly as much hassle as swapping the original CDs in. And if he has them archived to tape, then there's the hassle factor of having to update the tape archive every time he adds a new disk to his collection.

So let's settle this: how many CDs are in the collection in question?

That's because WAV files were never intended to contain metadata, and any support for it is a lousy hack, just like with ID3v1. Many of the lossless codecs do support metadata. Not to mention that the data you can get from the CDDB is so skimpy that you can easily contain it in the filename, even if you went with one that didn't support metadata. And the ones that do support metadata could contain more information that could be gleaned from the CDDB, thus preventing reentering that information every time.

Not to mention that the data you can get from the CDDB is so skimpy that you can easily contain it in the filename,

True. In fact, that was my suggestion to those who had been having the metadata-causes-pop problem.

Of course, I had neglected to mention that frequently a song's tag data contains characters that are illegal in windows file names such as /, ?, and *, so you still have the hassle of fixing up the tags of those particular songs...

So let's settle this: how many CDs are in the collection in question?

Okay, barring an immediate answer on this question, let's take a hypothetical 300-CD collection.

Let's assume that, on average, a raw WAV rip of that CD will occupy 600 megabytes of space. Times 300 CD's, that 175 gigabytes of raw storage. Half of that is about 87 gigabytes.

So If the collection is only 300 CD's worth, then I could see how someone might be able to justify spending an entire hard disk (or two) on storing the loslessly-compressed version of these audio files. But if you don't have 90 gigs of spare space that you never intend to use for another purpose, then we're talking offline storage, and that's a complete pain in the ass, even with a high-capacity SDLT drive ($$$)...

Yeah -- the wonderful vagaries of the Windows filesystems.

You could use a real operating system, like any of various free Unices, whose filesystems allow any character except `/'. (And, as an added bonus, have a scripting language that would allow for performing the transcoding very easily.)

Under Windows, I solve this problem by using URL encoding (`/' == `%2F', etc.), but then you have to figure out a way to decode that.

You mean that most people don't have 100-tape robot-controlled AIT-3 libraries lying around?

I've got probably at most a couple hundred cd's at this point. Only about half of that is in rotation at this point, but I want to get it all in a library and not muck with it anymore. I could justify a big fat drive for this, and still leave some growing room.

I wonder how likely it is our guys in England would implement FLAC support on our favorite toy.

Greg

unless you can convert direct from losless compression to whatever lossy compression format

#!/bin/sh



echo Converting $1

echo to $2...



flac -c -d "$1" | lame --nohist --vbr-new -h -k - "$2"

id3cp "$1" "$2"

#!/bin/sh

echo Converting $1
echo to $2...

flac -c -d "$1" | lame --nohist --vbr-new -h -k - "$2"
id3cp "$1" "$2"


Thanks, nice to see it's possible. Unfortunately, I wouldn't know even where to start to put this into... Am a bit of a computer simpleton..., particularly compared to all the geniuses resident to this board.

Ah, well you'll probably need a Linux box. You might be able to get this working on Windows under Cygwin, but it's not for the faint-hearted.

I've been toying with FLAC since last night and it sure seems sweet AND easy to use. Looks like it's right up my alley. The only problem that's holding me back at the moment is an issue with ID3 tags. Looking in freedb or whatever, I see the reference to my CD, it's got all the proper information with genre and year, and the rest.

When running GRIP, it pulls up almost all of this information, but for some reason omits the genre and year. The normal cd player under redhat in fact does pull up the genre and year information correctly tor this CD.

After some looking late last night, I found that GRIP doesn't support ID3v2 out of the box, but there's a patch. After applying the patch, I looked at the source and it SHOULD now be getting the genre and year information. However, even with the new build it doesn't appear to work, still.

*** Tag information for Let Me Touch You For Awhile.flac
=== TIT2 (Title/songname/content description): Let Me Touch You For Awhile
=== TALB (Album/Movie/Show title): New Favorite
=== TYER (Year): 0
=== TRCK (Track number/Position in set): 1
=== TCON (Content type): (12)
=== COMM (Comments): (ID3v1 Comment)[XXX]: Created by Grip
=== TPE1 (Lead performer(s)/Soloist(s)): Alison Krauss + Union Station

Anyone got any other recommendations of Gui'd rippers (if possible) in linux that are more exhaustive in collecting id3 tags?

Greg

Did more reading, looks like FLAC only wants integer math on the decoding side, and takes up little cpu ... sounds promising for the empeg.

Rob, Hugo, any comments?

Greg

Well, first, it does seem to be getting the Genre. That's TCON, which it's assigned to (12), which is a pointer to the ID3v1 Genre, which is Other. Check to see if other files get Genres other than ``Other''. (Try using the word ``other'' more in one sentence. It's a challenge!) It might actually be filling that in properly.

As for the year, make sure that you're pointing at FreeDB and not CDDB, because the CDDB that you'll have access to from GRIP will not have Year information. That's only available in CDDB2, which I doubt GRIP has access to, since it requires that developers pay money for it and also requires that the CDDB logo be displayed in the app.

Still couldn't get things working just right in Grip ... I gave up, found a command line tool that does more like what I want anyway ... little interaction for big batch runs. It's called autorip. It still didn't have genre and year, but after some hacking in perl (first time hacking in over a year, first time ever in perl!!!) I got it working just right.

Drop in a cd after starting the script. It will start ripping wavs, then convert to flac, adding in id3v2 tags with everything including year and genre parsed out correctly. You get a folder of Artist/Album/Song.flac ... you'll of course want to modify the default folder location (currently buried in /root).

You'll probably need MPEG::MP3Info if you don't already have it.

Greg

I wonder how likely it is our guys in England would implement FLAC support on our favorite toy.

I'd really like that too. In little time cost/mb will be so low that there will be no need for loss-compression, I think. I personally would not hesitate to use flac rather than mp3 even if I "only" had two 120Gb hdd in my empeg, rather than the two 30Gb ones I currently have.

I was just looking at the FLAC website again, and noticed that it's now implemented on the Phatbox. Empeg guys, for the first time ever, it's looking like you need to play catchup!