Cue Sheet Support

[GoogleCodeExporter]

Not a problem but a long awaited feature. Embedded or in separate files,
cue sheets would allow us to scrobble tracks from CD images. That would be
great.

Original issue reported on code.google.com by timochka on 20 Jan 2009 at 9:59

[GoogleCodeExporter]

Cuesheets are such a cludge. What speaks against splitting them?

Original comment by towolf on 21 Jan 2009 at 12:18

[GoogleCodeExporter]

In some sense I agree. I've tried some cue sheet plugin in the past and I 
wouldn't
say I was happy with it, and I didn't manage to find this plugin again. Also, I 
can
vaguely remember some implementation problems discussed somewhere (with 
seeking?).

Splitting is what I actually do, but this is not always the best option because 
it
introduces noticeable gap between tracks. I wonder if there's some other way to
achieve gapless playback.

Also, some people consider whole CD images the true way to create an accurate 
rip.
I'm not a ripping expert though.

Original comment by timochka on 21 Jan 2009 at 12:46

[GoogleCodeExporter]

This is being worked on here: 
http://code.google.com/p/quodlibet/issues/detail?id=49 . It makes playback 
perfectly gapless, in the true sense. But there are still bad bugs to iron out. 
And, unless you use audio CD 
images as an intermediate format to burn them back to CD eventually, you are 
always better served with 
single files. The internet is full of purists, or nuts if you prefer. Oh, and 
that’s »kludge«, right?

Original comment by towolf on 22 Jan 2009 at 1:33

[GoogleCodeExporter]

Probably this is the answer. Thanks.

Original comment by timochka on 22 Jan 2009 at 6:24

[GoogleCodeExporter]

I argue that embedded cuesheets enable the consolidation of an entire album 
into a
SINGLE FILE! And simplicity(1 file) > simplicity(many files), yes?

Also, I've found it quite painful to split images in Linux... I've written a 
clumsy
bash script to do make the task easier, but I still have to handle the metadata 
by
hand. Oh how I miss foobar2000! Wait... I suppose I could just use that under 
Wine,
eh? But what I would prefer is for QL to make that unnecessary.

It doesn't really matter if you personally don't and wouldn't use cuesheet 
support.
Some of us would, thus, the feature request stands.

Original comment by djpha...@gmail.com on 23 Jan 2009 at 12:49

[GoogleCodeExporter]

I argue that most audiophiles are migrating/have migrated their music 
collections to
single-file Flac files with cuesheets (embedded or not).

While many players in Linux have some sort of support for cuesheets, there is 
only
one I know of with support for embedded cuesheets in flac's and wv's: it is 
called
'qmmp' and can be found here:

 http://code.google.com/p/qmmp/

it is under active development - svn trunk has this feature enabled already

it would be nice to have options, hopefully this will make it into quodlibet 
soon as well

Original comment by lvb...@gmail.com on 21 Mar 2009 at 5:50

[GoogleCodeExporter]

There's no standard for cue sheet metadata. It is by no means a trivial 
enhancement,
and it will break much of quodlibet and its plugins to support this. (Literally 
every
one of the 'components' in use in the tracker would be affected, hence the list 
of
tags.) As you mentioned, it's poorly supported in the Linux world. The audio 
backends
currently don't have a fix for it, meaning that seeking would be imprecise and 
that
events would be generated by polling the timer. No devices that I know of 
support any
variant of this. Gapless wouldn't work without changes to the backend file, 
which are
already underway. And shntool splits images from cue sheets just fine, which 
can then
be tagged by QL/EF with info from MusicBrainz or CDDB and even remerged into a 
single
file later if the need arises, so there's no reason anybody actually needs to 
keep
their collection as single-file FLACs. 

How is this *in any way* a win for the user?

I'm closing as WontFix for now. Please provide some evidence as to how this 
approach
is better if you would like to get this reopened. (And the 'one file is simpler'
argument doesn't count. This is akin to saying "having /dev/sda only instead of
/dev/sdaN for each partition is better because there's less in the /dev/ 
directory."
It's not a UNIXy approach, nor is it a particularly sane one, and it only makes 
it
harder to actually do anything with the file other than listen straight 
through.)

Original comment by steven.strobe.cc@gmail.com on 25 Mar 2009 at 12:35

• Changed state: WontFix
• Added labels: Component-Browser, Component-Docs, Component-Library, Component-Mutagen, Component-Player, Component-Plugins, Component-Tagger, Priority-Low, Type-Enhancement
• Removed labels: Priority-Normal, Type-Defect

[GoogleCodeExporter]

I still see a need for cuesheets for a large portion of my music collection, 
namely DJ mixes. Cuesheets enable one to tag the audio file with the ARTIST 
being the DJ etc., while still allowing one to see the individual artist and 
title of each track in the mix.

I've looked at QL's code, and I'm convinced that limited support for at least 
displaying individual track information would be fairly easy to implement.

Original comment by crcul...@christopherculver.com on 26 Jun 2010 at 12:01

[GoogleCodeExporter]

Why not use a different tag for the DJ, for example albumartist or a custom 
one? Or use the DJ as artist but put a composer tag in.

I have split quite a lot of files using cue sheets, but I do prefer that method 
to huge files which are impractical and even impossible to use with media 
devices etc. I think the only reason to use cue files is gapless playback, but 
QL has it so why bother.

Original comment by finnpant...@yahoo.com on 26 Jun 2010 at 3:23

[GoogleCodeExporter]

"Why not use a different tag for the DJ, for example albumartist or a custom 
one? Or use the DJ as artist but put a composer tag in."

Because DJ as ARTIST is a longstanding tradition.

"...even impossible to use with media devices etc."

Rockbox has excellent cuesheet support. I love Quodlibet and couldn't use any 
other music player on my Linux box, but it's rather sad that I get more 
functionality when I copy the audio file onto a media device with severe memory 
and UI constraints than the powerful, expansive Qoudlibet. 

Original comment by crcul...@christopherculver.com on 26 Jun 2010 at 8:30

[GoogleCodeExporter]

Maybe what needs to be done is figure out what the actual user stories are for 
cue sheets, throw out the ones that are there because other players suck 
(gapless playback, filesystem management) or are not really related to being a 
good player (accurate CD re-burning, while a reasonable feature, is not 
relevant to anything QL does), and figure out some not-actually-cue-sheet 
extension to QL's own library format to fill in whatever cases are left in a 
sane way.

Original comment by joe.wreschnig@gmail.com on 28 Jun 2010 at 1:11