cuesheet support

2009 year yet
this is great idea, but i think author exaile can't make this support =(

> this is great idea, but i think author exaile can't make this support =(

Now when was that said? Implementing cuesheet support is just difficult and low-priority, not impossible.

Well, I don't think it's so difficult. CUE is an ordinary text file with simple syntax:
http://digitalx.org/cuesheet.php
And seeking is also very simple operation. So all what you need is small CUE parser. And some improvements to collection manager.

But CUE sometimes is very usefull. A lot of people prefer to store their music not in single tracks with tags, but in one file per album with CUE. Most popular free lossless codecks FLAC and WavPack completely support CUE, WavPack even use it as basic place for information when pack album with lyric, artworks and so on in one file .wv.iso. (By the way, supporting it will be also great;)) Many peoples has such files, and many has simple image+cue, in Windows there isn't a problem with CUE because the most usefull (and the best for microsoft creation;)) player Foobar supports it, but in Linux there is a lot of problems, so many peoples use Foobar with Wine for listening their music collections. Moreover, CUE automatically generated by default when ripping CD with EAC, and EAC now is the most popular (and also the best for Windows) ripping program for melomans.

I really don't understand why you consider that CUE isn't widespread. CUE is rather handy and standard alternative for tags, and I think that player should support it, least because СUE is one of the metadata's field in official FLAC specification, and full support of FLAC is clearly needed for good player;).

In software development there are little hard tasks by itself, one of them is to combine thousands of small and easy features.

As I see the complexity comes from the notion of 'virtual file' song, or something like that, while internally some parts rely on the fact that song is a real file. Of course this is solvable problem, but requires rewriting some internal API, that's why author considers it difficult and low-priority.

Meanwhile, you can use shnsplit to achieve happiness :)

Here is the script I use (just put it into your ~/.bin/split_to_flac )

if [ "$2x" == "x" ]; then
  echo 'Usage: split_to_flac <cue_name> <source_file>'
  exit 1
fi

# split files
##cat "$1" | shnsplit -o flac -t '%n - %t' "$2"
cat "$1" | shnsplit -o flac "$2"

# some rips have zero track
rm split-track00.flac

# set tags
cuetag "$1" split-track*

for i in `cueprint -t '%02n ' "$1"`; do
  name=`cueprint -t '%02n - %t' -n $i "$1"`
  mv split-track$i.flac "$name.flac"
done

> Well, I don't think it's so difficult. CUE is an ordinary text file with simple syntax:
http://digitalx.org/cuesheet.php
Parsing the CUE itself is very easy, its just integrating that into the rest of exaile, specifically the playback engine, that is harder. The playback engine has to be redesigned to be able to treat parts of files as single tracks and to transition between consecutive tracks within cuefiles smoothly and correctly, which is non-trivial to get right.

> I really don't understand why you consider that CUE isn't widespread.
We never said that, just that it was low-priority due to the aforementioned complexity. We would love to have full CUE support in exaile, however at the moment there are more-pressing concerns to deal with.

I do to want CUE sheet support in Exaile. I find it the best player around - Ubuntu 9.04 here . I am new to Linux. All my audio collection is ripped FLAC + CUE. That's standard audiophile practice. I don't understand why is is low priority. It should be high priority. It is a missing feature. I wish someone as the knowledge and time to produce a similar application as foobar2000 for Linux: Play/tag/encode. Thanks

> I don't understand why is is low priority. It should be high priority. It is a missing feature.
Because it is complex, and is also as you say, a FEATURE. Not a bug, or a regression, or a core framework, a feature. New features take lower priority to other bugs, and this one is particularly complex, hence why it has gone so long unimplemented. It is on our list, we plan to implement it eventually, but we are not going to prioritize it over more-important matters.

One possible implementation is within djmpc (http://git.blakesmith.me/djmpc/tree/djmpclib) Should be feasible to make something from this.

Dear Aren, maybe you're not familiar with it, but classical music is mainly fond in internet in Image+Сue.
I, personally, have few hundred gigabytes of music in Image+Cue, part of it is on ROM. So it is impossible for me to use Exaile.

By not supporting cue, you cut off listeners of classical music. If that's OK for you, well... good luck!

@mikropolip - As I've said time and again, its not that we don't WANT to support it, its just that there is a significant amount of effort involved in making it work. Why do you think so few linux players support it, if it were easy to implement in the first place? It is something we plan to do, but we will get to it when we get to it, and no amount of begging, complaining, whining, or bribing will change that.

Mathias and I were discussing what it would take for us to support cue sheets. I'm also checking the behaviour of foobar2000, which supports cuefiles and whose tagger is _good_. The following are some of the ideas/findings:

- We can represent the URI of each track as file:///path.cue#01 (or #1; doesn't matter I guess). This means that we have to read the cuefile for each track played, but I don't think it's a big deal.

- Alternatively, we can also represent it as file:///path.ogg#100.0-200.0 (file, start, end). The problem with this is we lose the cue filename (required for tagging), so it has to be either encoded in the URI or stored somewhere else in the metadata.

- The cuesheet spec only supports some formats from the stone age (including mp3). fb2k simply specifies WAVE for Ogg/Vorbis or other formats.

- At album level, fb2k supports PERFORMER "Artist", TITLE "Album", REM DATE 2000, REM GENRE Genre, REM COMMENT Comment, and perhaps others. It also adds tags specified in the original music file, although preferring tags from the cuefile.

- At track level, fb2k supports PERFORMER "Artist", TITLE "Title", and REM DATE 2000. Perhaps also songwriter, though I didn't try.

- Technically, with the REM syntax we can support anything. fb2k does not do this; some tags will simply not get written, and the album-only tags can't be attributed to individual tracks (which makes sense for genre and album, but not for comment).

- In general, handling differences between album- and track-level tags will be somewhat tricky.

- There can be an album artist and (for each track) a track artist specified. fb2k is really smart when it comes to handling various album/track artist situations (for example, If all track artists are the same and there are no album artists specified, it will be written it to the cuefile as the album artist instead), but we can get away with a simple implementation first.

- We have to handle the case when the user tries to modify an album-level tag (e.g. album artist) on 1 track only. Do we change the album artist from all tracks in the album? Do we refuse to make the change unless all tracks are selected? fb2k is somewhat buggy in this; it will remove all instances of that tag instead.

Another thing:

- The collection scanner may need to be modified so it doesn't add files for which .cue files exist. I think assuming the .cue file and the music file have the same "base" name (e.g. file.cue and file.ogg) is an OK compromise.

Johannes - well, .cue files specify the file names they are associated with in themselves, so as long as we parse any .cue files in a directory first so we know which 'real' files to ignore, there shouldn't be any need to assume.

I think the file:///path.cue#01 uri syntax makes more sense than the time-based one. It much more clear exactly which track is being referred to, and the overhead of re-parsing the .cue should be minimal. (or we can just store cue offsets and such in special internal tags)

As for tag editing at an album level, we could edit it across all tracks in the album and just use a gtk.InfoBar to warn users that it will affect more than the selected track.

> Johannes - well, .cue files specify the file names they are associated
> with in themselves, so as long as we parse any .cue files in a directory
> first so we know which 'real' files to ignore, there shouldn't be any
> need to assume.

I'm more thinking about the case if the cue file is referring to a
file in a different directory (the spec allows this), in which case
the file may have been scanned previously.

Obviously we can still handle this perfectly, by removing a file from
the collection if we find a cue pointing there. Just a bit more work.

Is there any news about this?

Can we expect one day Exaile to support cuesheet files (5 yeas since feature request !) ?

Pleeeese releeeeeease!