En r�ponse � Steve Lhomme <[EMAIL PROTECTED]>: > En r�ponse � Josh Coalson <[EMAIL PROTECTED]>: > > > --- smoerk <[EMAIL PROTECTED]> wrote: > > > good idea, i'm always putting *.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 > > Mmm, yes the CDDB feature would be great. Is it based on an ID per disk > or an ID > per track ? If so, how do you want to integrate it on a track basis ? > (CD ID + track number ?)
Never mind, I found the information I wanted : http://www.freedb.org/modules.php?name=Sections&sop=viewarticle&artid=6 The CDDB ID is computed with data in the CD TOC. It's not something that is written on the CD (too bad). For integration on a Track basis, the ID would be to store in each track/file the Disc ID, the CD-track number and the CD-index number. Then when you have all files from a CD with all these informations you can reconstruct the CD the same way it was originally (well, not exactly, but a decent copy). So in MCF, I added a DiscID element in each Track, a DiscTrack and DiscIndex elements in the audio Track properties. To have a full CD, you will need to use a different Segment for each track. Otherwise you can use Chapters to "virtual cut" the data, but you'll be missing the CD features (Track number, index number). ------------------------------------------------------- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en _______________________________________________ Flac-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flac-dev
