similar to: cd archival (revisited/again)

On Thu, 2003-12-25 at 21:35, Josh Coalson wrote: > --- jason <jason@doomba.com> wrote: > > is there a cuesheet syntax document someplace? > it's not really standardized that well. there are some links > here: http://flac.sourceforge.net/documentation.html (search > for --cuesheet) hmmmm.... i just reread the faq and your right... i'm kind of losing interest in

On Wed, 28 May 2003, Josh Coalson wrote: > interesting idea, CD-TEXT is in the subcode and if cdrdao can > split it out that's better I think than hacking the CUESHEET > block to store CD-TEXT. I suppose the ideal would be to have a metadata block to store the subcode from a CD, and something that could interpret it as CD-TEXT, if that's what it is. Then it would be possible to

--- Curt Sampson <cjs@cynic.net> wrote: ... > Next, I rip the entire CD using cdrdao. This generates a .bin file > containing the raw audio data and a .toc file containing the table of > contents of the CD. There's still a problem here: I don't have the > subcode data (from channels R through W). There's a possiblity that > cdrdao will keep CD-Text data, since the

I've just started to archive my CD collection (about 800 CDs), and my criteria are pretty much the same as the original message under this subject, except that I'm doing one file per CD. One file per song is just too much of a pain, and there's really no need, given FLAC's ability to have metadata in the file. The first thing I do is run cd-discid against the cd, and store that

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

Hi there, is there any specific reason for ignoring TITLE and PERFORMER info when importing CD-TEXT cuesheets into flac files? (These two fields have not always been used but they have become widely supported by now). One may answer that the preferred method for getting this kind of info for a cuesheet-flac would be CDDB, but CDDB info is not always reliable. In my opinion the goal "Now a CD

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Phillips wrote: > With regards the toc problem not compensating for starting from track > 0, is it possible to use the cdrtoa -t or -T options to compensate for > the shift. I am not sure I fully understand the option, but I came > across it and thought I would mention it. I believe the -T and -t flags (to cdparanoia? AFAIK, cdrdao

--- Curt Sampson <cjs@cynic.net> wrote: > 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 >

Charles Steinkuehler wrote: > Dan Phillips wrote: > >> With regards the toc problem not compensating for starting from track > >> 0, is it possible to use the cdrtoa -t or -T options to compensate for > >> the shift. I am not sure I fully understand the option, but I came > >> across it and thought I would mention it. > > I believe the -T and -t flags

Hi. I these questions are copied from a forum and perhaps you can help me to answer them. I) For some codecs (I think MP3 for example) there was that issue that you have different sample/frame/whatever lenghts than in raw/wav encoding, thus if you encode a file to mp3 the lenght is not exact and some digital silence is added. Is the same thing the case with flac (thus the original file would be

I see that this was the right place to fire off this question. Thanks for your feedback. It has given me a base to start some trials. I used to use EAC on Windows, but I tend to only use open source software as much as possible and I don't use Windows any more. I gave a brief look at abcde, but it is clear I need to look at this some more. It looks like it has the potential to do everything I

Josh Coalson wrote: >> III) I've read about the CUEsheet feature of flac where you can store >> the data of cuesheets (at least indices and so) as searchpoints in >> flac. >> But the format seems to be in milliseconds while in CDDA frames are >> exact. >> Is it (because one would have rounding errors) not adivsable to use >> this >> feature, and

On 5/23/06, Michael Kiermaier <michael.kiermaier@gmx.net> wrote: > On Sunday 21 May 2006 23:31, Neal B. wrote: > > A picture is worth 1000 words, so here is a screenshot: > > > > http://img62.imageshack.us/img62/2783/fplayshot4yy.png > > Hi Neal, > > currently I am looking for a flac-player on Linux that understands internal > cue-sheets. So I am very

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,

>I can see the other side of the arguement too tho, there may be many >players around now, and in the future that will add flac support, but >not flac-album support :( yes this would be my concern as well. also, individual track support is just more flexible for moving music around between devices. it's funny, i've been on-and-off trying to get the whole eac+flac+id3+cuesheet

Hi all, Using the FLAC++ level 2 metadata interface the following function doesn't do what you would expect: cuesheet->get_track(i).get_num_indices(); (where cuesheet is a FLAC::Metadata::CueSheet *) It returns a bool instead of an int, why is this? To get the mumber of indicies in a track I need to use: cuesheet->get_track(i).get_track()->num_indices; ie. retrieve the C struct

It seems like single file flac with embedded cuesheet is a pretty good solution to archiving a cd collection and avoids issues with track gaps etc. What's the situation with player support for these files? It seems that most players I've seen assume 1 file == 1 song. Stephen.

Hi. I these questions are copied from a forum and perhaps you can help me to answer them. I) For some codecs (I think MP3 for example) there was that issue that you have different sample/frame/whatever lenghts than in raw/wav encoding, thus if you encode a file to mp3 the lenght is not exact and some digital silence is added. Is the same thing the case with flac (thus the original file would be

Josh, Sure. I can try. Would you give me a more detailed description of the requirement ? What exactly does "general MM:SS handling" mean ? Earl ________________________________ From: Josh Coalson <xflac at yahoo.com> To: Earl Chew <earl_chew at yahoo.com>; "flac-dev at xiph.org" <flac-dev at xiph.org> Sent: Tuesday, May 1, 2012 8:25:34 PM Subject: Re:

--- smoerk <smoerk@gmx.de> 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