Sean, Thanks for the detail. And, yes, it does clarify. Funny you brought up EAC. I just downloaded it last night. But all I could find on the site was a series of Betas with no final. Are you using the latest Beta version, or am I looking in the wrong place?
Mike ----- Original Message ----- From: "Sean Goller" <[EMAIL PROTECTED]> To: "Slim Devices Discussion" <[email protected]> Sent: Wednesday, April 06, 2005 10:28 PM Subject: Re: [slim] metadata musings > Mike Hartley wrote: > > Sean, > > PLEASE forgive my ignorance on this topic, but I'm interested because I am setting up a new dedicated server on a 3G wireless network for a new SB2 and am making format decisions. Specifically, this discussion of meta-data for the file has me interested. Is this basic track, album and articst information, or are you discussing additional information beyond this? > > > > I'm trying to decide whether to keep the server as is with Win XP and copy my files over in their current state as WMA lossless or re-rip or convert everything to FLAC. I was also considering the radical step of using a Linux Deb distro for the server in conjunction with FLAC and bagging Win XP altogether. > > > > However, this and some other research are giving me some second thoughts. From this and other discussions here, it seems that FLAC files can be difficult to create and manage. If the info you are talking about is the title/album/track/genre stuff, I find Win Media player retrieves it pretty reliably and ripping is super easy. Forgetting my inherent dislike of MS, if it's really that much more of a pain to manage ripping and tagging in FLAC, what's the advantage other than open format? > > > > Help me out here! :-) > > > > Mike > > > > Warning: Grandiose Plan Discussion Ahead > > What I am trying to accomplish is to create a complete lossless archive > of all my CDs. By "complete" I mean I can accomplish anything i'd want > to do with the music on the original CD with the data in this archive, > without having to go through the drudgery of swapping CDs for days when > I want to perform some operation on my entire collection. (like encode > to the new lossy format of the day) FLAC gets me that, because I can use > EAC to rip the CD to WAV, encode that WAV to FLAC and embed the cuesheet > into the resulting image. That single file has enough information in it > to get me metadata information from musicbrainz or freedb whenever I > want it. I don't have to worry about the directory structure I've chosen > to store the images in, filename conventions, or anything. All I need is > the data in that file, and that data will *never* change. For all > intents and purposes I can mount whatever drive it's on read-only. > > This attitude towards metadata is especially key with "relatively" > volatile metadata storage, like musicbrainz. If I treat metadata as > being external information that's cached as opposed to *part of the data > itself* then it's much simpler to update and maintain. The simplest and > most resource-abusive example is every time slimserver loads up a FLAC > image, it calculates the CDIndexId and fetches the metadata from > musicbrainz and caches it locally for reference while any track from it > is being played. Now SlimServer is *guaranteed* to have up-to-the-second > track information from musicbrainz. Would I suggest doing this? Heck no, > I pay for server bandwidth too. But writing a script that once a month > slowly walks through your collection updating metadata isn't beyond the > realm of possiblity. > > In specific response to your question, it doesn't matter what the > metadata is. Since the CD's TOC is derivable directly from the FLAC > image, you can use that information to generate whatever token > (musicbrainz CDIndexId, freedb DiscID, what have) you need to get > metadata from the internet. > > I guess part of this comes from how you view music. Most ripping > software uses the track as the atomic unit of data, since that's how > people listen to it, individual songs. But once you start talking about > keeping a network-based copy of your entire music collection around, it > doesn't really make as much sense to break it down that far. FLAC > (especially with version 1.1.2) makes it very easy to extract TOC-based > sections of data from an image, which means it's easy to create > track-based "export" versions of your library. I don't care if the hot > new music player only plays AAC and doesn't understand FLAC, I can write > a script that walks over my entire archive and export everything to AAC, > with the appropriate metadata fetched from a cache or on the fly. And > two years later, if I junk that player and get another one that only > plays OGG, I can delete my AAC library and re-export everything to OGG, > with little to no human intervention. SlimServer doesn't care if your > music storage is track-based or album-based, as long as it can get to an > individual track and provide metadata to the listener. > > As for FLAC creation and management, I highly suggest you look at > flacattack (http://www.uninformative.com/flacattack/) which coupled with > EAC (http://www.exactaudiocopy.org) is what I'm using to create FLAC > images. It's simple and relatively fast, depending on your hardware. > What I will probably end up doing is making a modified version of > flacattack that names the file according to the musicbrainz CDIndexId, > or Josh's hash if he cares to share the algorithm. :) > > Whew! > > Hope that answers your question. :) > > -Sean. > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.slimdevices.com/lists/listinfo/discuss _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
