search for: cdindex

...te of under 300kbps which is not bad for lossless. The other interesting thing is that the sweet spot seems to be more near -4 than -5. Josh P.S. My next project is to rip and encode all my CDs and store the CD metadata in a database. I've got a nice schema worked out and a better hash than CDindex for creating a primary key from the CD TOC. If there's interest I can publish the code for the little TOC reader + key generator (UNIX only, gotta love ioctl). __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Mes...

I've put together the first attempt to defining an RDF metadata vocabulary for use with the CD Index/MusicBrainz/OggVorbis. If you care about metadata issues, please take a look at: http://www.cdindex.org/MM I've included a section for video specific stuff, but everything that I originally had in there is being covered by the MM:Contributors section. The Contributors stuff will allow us to easily identify producers, directors, actors and other people who were involved with the creation of t...

....cue files to the directory with the > ripped audio files. but it would prefer one file per song and not one > big file for the whole cd. My vision of how the players should work is this: - make one album.flac with CUESHEET - player loads album.flac, sees CUESHEET, calculates CDDB id (or CDindex, or custom hash), looks up metadata in database - player presents album.flac as separate tracks - playlists can reference individual tracks in album.flac Josh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.y...

On Tue, 27 May 2003, benny k. wrote: > I'm a little embarrased because its just a hack on metaflac, but if you > want it, i'll post it one my webpage. it should be easy to modify it for > use with a CD image. Why don't you submit to the sourceforge feature request queue as a patch? That way it will be there for anyone who wants to hack on it. Although maybe this kind of

Speaking of Metadata, how's work going on the definition? Looking back at the list archives, there seems to be a semi-plan to use Robert Kay's DTD from http://www.cdindex.org/dtd/TrackInfo.dtd, but I'm conserned that it's too specialized for video and we'll end up having a special case for audio-only files. There are a couple of general issues here. Micheal Smith suggested on irc that an important distinction to make is between "timecoded" dat...

Dear list Sorry to ask a user's question on developer list. I didn't find the user list. I am experimenting with --cuesheet and encoded a flac file with a cuesheet. Result is: * Totem on opensuse 10.2 opens the flac file with no meta data, no play list. "Next" button doesn't work; * Mplayer on opensuse 10.2 opens the flac file with no meta data,

Hi all, I started up a discussion on Hydrogen Audio about a new FLAC metadata block for storing cuesheets. This is really the last missing piece in archiving CDs. Here's the link: http://www.hydrogenaudio.org/index.php?act=ST&f=20&t=4646 I would appreciate any feedback anyone has on the subject. If it's not too inconvenient, try replying on the forum there (not sure if you

...t; > ripped audio files. but it would prefer one file per song and not one > > big file for the whole cd. > > My vision of how the players should work is this: > > - make one album.flac with CUESHEET > - player loads album.flac, sees CUESHEET, calculates CDDB id > (or CDindex, or custom hash), looks up metadata in database > - player presents album.flac as separate tracks > - playlists can reference individual tracks in album.flac > > Josh Ditto, thats how it works for REAL cd's, there kind of in one 'file' so to speak. Can you put single CD tr...

...ceforge feature request queue as a > patch? That way it will be there for anyone who wants to hack on it. > > Although maybe this kind of stuff really wants to be added to > flac-tools. Is anyone still working on that project? I don't think so. I am planning to add CDDB index and CDindex generation methods to libFLAC, which will compute them from the CUESHEET metadata block, and then adding metaflac options to get them. We're also considering mergign flac123 from flac-tools into the main flac codebase. Josh __________________________________ Do you Yahoo!? Yahoo! Calendar -...

Thank you Josh, the link clearly explains FLAC's philosophy and it souds quite logical: "For FLAC the intention is that applications can calculate the CDDB or CDindex ID from the CUESHEET block and look it up in an online or local database just like CD rippers and players do. But if you really want it in the file itself, the track metadata should be stored separate from the CUESHEET, and already can be because of FLAC's metadata system. There just isn't...

...ossless. JC> The other interesting thing is that the sweet spot seems JC> to be more near -4 than -5. JC> Josh JC> P.S. My next project is to rip and encode all my CDs and JC> store the CD metadata in a database. I've got a nice JC> schema worked out and a better hash than CDindex for JC> creating a primary key from the CD TOC. If there's JC> interest I can publish the code for the little TOC JC> reader + key generator (UNIX only, gotta love ioctl).

Hello, I managed to insert cuepoints from a cue sheet and check them with metaflac. I witnessed that the FLAC headers then had additionnals sections (one for cuepoints and one for seekpoints), but i could not find documentation how the format used to store them (frame counts for both ?). Anyway it seems that cuepoints must be specified in MM:SS:fr format. It would be nice if those could be

I discovered FLAC earlier this year, and wrote flac-archive to archive my CDs to single FLAC files. I've been archiving my collection for months now, and have gotten it to a reasonable level of stability and robustness. I recently looked over this list's archive and saw a number of questions about doing this, with no clear solution emerging. So, here i am to offer my meager tools.

I've come full circle on the Ogg text stream format, back to arbitrary associated xml streams. What's changed? Mostly rolling the requirements around in my head, and weighting them differently. I think we've dealt with the complexity issue; this functionality can be optional for "dumb" audio players, and possibly also for dumb video players, though there it's a smaller