Expected behavior for FLAC embedded cue sheets

Discuss the development and future direction of Play.
Post Reply
User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Expected behavior for FLAC embedded cue sheets

Post by sbooth » Mon Oct 22, 2007 5:00 am

I've gotten playback working for FLAC files with embedded cue sheets. An issue has come up that I'm not sure how to address; specifically-

What do users expect when editing properties for a track that is part of a larger file?

This applies to metadata, PUIDs, Replay Gain values, MusicBrainz IDs- the whole shebang. I can envision several possibilities for behavior. In no particular order, they are:
  • The relevant data in the original file is overwritten with the changed information
  • The original file is left alone
  • The user is prompted asking whether to save changes to the original file
In my opinion writing anything track-specific to the original file is bad, so I am leaning toward option #2.

Thoughts?

maxlover
Posts: 36
Joined: Sat Apr 07, 2007 6:37 am
Location: Belgium

Re: Expected behavior for FLAC embedded cue sheets

Post by maxlover » Mon Oct 22, 2007 6:05 pm

I've gotten playback working for FLAC files with embedded cue sheets
That's really quite exciting news.
What do users expect when editing properties for a track that is part of a larger file?
The best, what else ? :)
In my opinion writing anything track-specific to the original file is bad, ...
Certainly. There is indeed no place to put track specific information in a multitrack FLAC file with CUE, by design.

If the file is the image of an album, it is a question I have been thinking about for a while (see tracker issue 340).

It seems that the album-global information has its place in the FLAC metadata. When ripping an album, Max does indeed write this information at the right place in the file. If the album-global information is modified for one of the tracks, I would expect that modification to apply 'automatically' to all the tracks, and to be written back into the file metadata. This includes the Replay gain for the whole album, if available.

Since there is no room for track-specific information in the file, it must be written elsewhere (of course). Certainly first in the Play database, but I would venture to say that it is not enough. The database may need to be rebuild for some reason, and it would be a pity to loose all the corrections and improvements encoded in the mean time. So where ?

But where does the information comes from in the first place ? For albums that have been ripped with Max, Play can find the information in the ~/Library/Application Support/xxxx.cdinfo file that Max produced. If the information is changed in Play, I would suggest that it should be written back into the .cdinfo file. This way, if the file is later converted using Max, or the CD re-ripped, the updated information will be used. And for albums that have not been ripped with Max, a fresh .cdinfo file could as well be created, so, if the file is later converted with max, etc... If this road is followed, the album-global information should also be updated in the .cdinfo file, of course.

The idea is the have Max and Play work together and share information.

Now, if the file contains unrelated tracks, I don't have anything sensible to propose, beyond the Play library. Is this a popluar way to use multitrack files ?

P.S. I really like that collection of .cdinfo files as 'the ultimate' repository of album and track data. After ripping my 936 CDs, and taking more than 200 hours correcting and improving the metadata, I now include them among my most coveted files, with multiple backups. My only regret is that, given the way their name is build, some of them are invisible. Would it be possible to put a fixed prefix before the computed part, so as to keep them all visible ?

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests