Support for cuesheets

[ghost]

This issue was automatically migrated from Google Code.
Original author: jmbyl...@gmail.com (February 28, 2012 04:14:16)
Original issue: google-code-export/beets#351

[phaethon]

I have ripped my CDs into multitrack FLAC files with embedded cuesheets. I use f2k on Windows and deadbeef on linux to play them.
I would like to be able to import these files using beets as separate tracks in the database, by leaving file as a single FLAC. At the same time being able to update tags in the embedded cuesheet by various means beets allows to update tags for separate files.

p.s. I don't see relation to #109 if cuesheet is embedded and we leave it as such.

[phaethon]

It seems that mutagen library does not currently support cuesheets embedded as FLAC tags. Neither a quick search gave me another python library, which does it. If anybody knows better, please, comment.

[sampsyo]

Do you know what the storage format is for embedded cue sheets? Given documentation on the subject, it might be straightforward to implement without library support.

[phaethon]

Format to my understanding is exactly the same as standalone cue sheets. I have created a class, which parses it and will add to github in a moment.
I have, also, submitted issue on cuesheet support in mutagen library on their issue tracker.

[phaethon]

At least for multitrack files created with foobar2000 cuesheet is saved as "cuesheet" tag in flac file. Deadbeef linux player also shows these individual tracks.
Theoretically, flac files can contain cuesheet metadata block, but it is not normally used for titles, etc. metadata. This type of cuesheet is supported by mutagen library, but I don't use those.

See the code here https://github.com/phaethon/beets/blob/master/beets/util/tagsheet.py parsing cuesheet and being able to regenerate it after changes.
Somewhat naive code, but it works with all of my files. Used with python2.7. Demo usage in main part.
Currently, case sensitive on command names. I have not seen anybody having lowercase commands in cue sheet.

I would like to be able to import a single flac file (with embedded cuesheet) and expect beets to treat it in the same way as importing folder of separate tracks. I guess it would require changes all around beets.

[sampsyo]

Yes, changes to support this in beets will be pervasive. Many parts of the code currently assume that a path uniquely identifies a track. To begin with, schema changes to support multi-track files will be necessary.

[zepplock]

It would be great to get CUE+IMAGE working. BNot just copy/attach cue, but parse and get track listing.

[sampsyo]

Continuing from #1257 for @brunal:

If I were trying to attack this, I probably would not start with the importer—I'd start with the data model. It would be an accomplishment on its own to extend Library so that individual Items can all refer to the same audio file but different positions in an associated .cue sheet. I'd recommend doing something like these steps, committing/testing each one in turn:

1. Extend the library model. Items would need to impose on the duration field. They would need to avoid overwriting their own tags to one central FLAC file. They would need to all have their paths updated at once when one file moves.
2. Then, make it possible to beet import a .cue-agumented file without autotagging (i.e., it only works in -A mode).
3. Finally, extend the entire autotagger pipeline. ImportTasks may need to be aware of this situation.

[andremiller]

And perhaps extend the web plugin so that when you request the file resource for a particular track it will seek to the correct position in the file and only return the track and not the whole file. This way it's transparent for players. (Not sure if this would require physically splitting / transcoding the file)

[brunal]

Well this is far more ambitious than what I envisioned :-)

Such features could be nice but raise issues. The one that bothers me most is how I would export a playlist with only the track #X of a single-file album. Keeping the original single-file album is convenient if I want to keep the inter-track moments, but that's the only benefit I can see.

Related discussion (centered around mpd's support of those files and their cuesheet) on archlinux bbs

[sampsyo]

Yes, it does seem like a tremendous amount of work. I, for one, am not totally clear on why single-file albums are desirable, but some people do seem to like them.

I suppose a kind of half-solution would be to automatically split out FLAC files on import, along the lines of the archive import feature?

[phaethon]

Splitting FLAC on import defeats the main purpose why people love these files. There are 2 reasons, why I love them:

1. Having whole album in a single file allows totally different organizing of the files.
2. No issues between tracks. Which is VERY important if you listen to classical/symphonic music, concert/opera/rockopera recordings (Phantom of the opera, Les miserables) or other music, which is meant to be listened as whole album not as a bunch of tracks (The Wall, Dark side of the moon, etc.)

[zepplock]

I'm really against altering actual files that go into the library. Adding cover art and tagging is ok but splitting flacs is not for many reasons. Prejudice like previous author mentioned and just time it will take (I have 4tb of flacs, some people have more)

Ps The 2) mentioned above is not true. My "the wall" flac with separate files plays as well as a single flac. At least in foobar.

[sampsyo]

Thanks for the feedback, @phaethon and @zepplock. The prevailing opinion is pretty clear: people want to keep these as single files. Meaning that this feature will, in fact, be a lot of work. 😃

[phaethon]

@zepplock depends on player, specific flac, and specific album. There are cases when it is not true, and many cases when it is true.

@sampsyo I am ready to participate with code, but I know nothing about current beets inner works.

[sampsyo]

Great! The Hacking wiki page has a brief intro, and the developer section of the main docs has more detailed API information.

[siebenstreich]

Yes, beets is the geek media organizer. But without doubt, a geek media organizer should understand monolithic FLAC files with embedded cue-sheets. For a full-fledged support of these files I would happily donate to this project!

Note that there are two common ways of storing cue sheets in a flac file, see ftrvxmtrx/split2flac#10 (comment)

[sdfg2]

Interestingly, both of the things I was thinking about have lead to this issue: automatically splitting monolithic flacs, and having multiple copies/formats of the same track held in the database.

My use case is, I get an album, and I want to add the tracks (obviously). If it's a monolithic file, I split the file (which is usually a trivial process unless there's something funky about it, like it was from an LP rip or something). I then import the (possibly newly split) tracks, which autoconvert to flac (via the convert plugin). I do 'beet bad' on the album, just to check everything is ok. Then I do 'beet convert -f opus' to get a mobile-friendly copy of the same album. All of this is relatively straight forward, but if I'm importing a large chunk of my collection at a time, it gets very tedious, very quickly.

I mentioned elsewhere about adding the ability to chain subsequent commands to the import command, which would streamline things, and certainly having the ability to split the monolithic file as an option on import would be extremely useful as well.

The biggest problem I have is if, when I discover there is a problem with a particular album I have in the library, I then remove it. Fair enough. But I then have to remember and ensure that I also delete the corresponding opus files as well (I use paths to organise). Having some sort of function to record multiple locations for the same track would be useful.

However I'm not just here to provide a long winded way of saying 'I agree' :-)

One idea I came up with is having a separate db table (as suggested) for the actual files. In my mind, that would consist of a [track foreign key, file location, file position] format. That way commands such as 'remove -d' would cascade down naturally. It would also mean monolithic files could easily be supported, once the information is read from the cue.

A problem I do see, however, is checking against MB. Every time I've (accidentally) tried to import a monolithic flac, it either can't find the album at all (I assume because of the chroma fp being weird), or if it does, it lists all the missing files, as it assumes it's just the first track. It would take some very clever pre-processing and possible re-engineering of the chroma fping method to allow it to fp only sections of a file, or, less elegant but more easy to engineer is to temporarily split the monolithic file, do all the checks from that (to ensure the correct album and so on), import the monolithic, and use the cue to assign the track positions for the file, then dump the temp files.

[proud-wolf]

hi all,

any updates ?

[sampsyo]

Hello, @proud-wolf! As a matter of respect, please don't post comments like this. If there are any updates, they will already be posted here---there's no information available beyond what you see in the thread.

Instead, if you're interested in this ticket, the most useful thing to do is to pitch in and help make some progress yourself! What form that takes is up to you, but participation is always appreciated.

[proud-wolf]

Hello @sampsyo,
my apologies - I don't mean to be or sound rude. I thought that I have missed the thread

I'd like to assist in solving the issue, but I'm less then newbie in Python :(

[daviddavo]

Could this be done in the form of a plugin that uses an external command?

https://wiki.archlinux.org/index.php/CUE_Splitting

[retrography]

Someone actually took a shot at that in 2016: https://github.com/beetbox/beets/blob/master/beetsplug/cue.py

[retrography]

Only if we could internalize this as a first step: https://github.com/ftrvxmtrx/split2flac
Or: https://github.com/ftrvxmtrx/unflac

[brainchild0]

If I were trying to attack this, I probably would not start with the importer—I'd start with the data model.

I don't know the system, but the above seems a sound inference.

It would be an accomplishment on its own to extend Library so that individual Items can all refer to the same audio file but different positions in an associated .cue sheet.

Again, not knowing the system, I suggest adding an Asset type, which would refer either to the single track or the whole album, depending on which is given by a file. Assuming Item is now the name for a file representing a single song, then I would name it instead Basic Item, which simply wraps a single Asset. The type Sequential Item might then represent a song in a whole-album file, given by the pairing of Asset (i.e. album) and Sequence Number (i.e. track id). If both Asset and Item have a separate tag set, then the tags of the Item would not clobber those of the Asset. Note that for external cue sheets an asset would be either the cue sheet file (which references an audio file) or the pairing of the two files.

The main objective should be not splitting an album but preserving it whole, though there are reasons for splitting it, as well.

[brainchild0]

I, for one, am not totally clear on why single-file albums are desirable

It preserves the full data of the original album, retaining the value but eliminating the hassle of the physical media.

[cmpute]

I'm personally developing tools for myself to organized single-file albums here https://github.com/cmpute/Fluss/blob/main/fluss/cuesheet.py. It already can parse cuesheet from standalone cuesheets, embedded cuesheets from flac, id3, ape tags. It also handles the override relationships between normal tags and cuesheet tags. Just list here for a reference if you guys are going to implement support for this.

I personally stored all my music using single-file format since it's easier to maintain and easier to check with AccurateRip. Maybe in future I will export some of my favorite tracks to separate files and organize them with beet.

[brainchild0]

Just list here for a reference if you guys are going to implement support for this.

It seems, from earlier discussion, the main obstacle for integration in this application is the constraints of the existing internal data model.