Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CUE files are unoptimal (Read 4289 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUE files are unoptimal

I made a post in a previous topic about CUE files. They could be replaced rather easily with a superior format. Presently, CUE files do not store meta-data. This is a little frustrating to people who don't desire to use the database, as they can't really edit the information. There are also seeking problems associated with CUE files and huge files in certain cases. An alternative to a CUE file could implement a seek-point measured in bytes to end the "slow seek times" complaint. I am unsure whether or not there exists a superior format, but by simply changing from CUE to something a little more advanced, you could kill two semi-bugs with one plugin/extension.

Now, anyone interested?

CUE files are unoptimal

Reply #1 –
Do cue files allow comments?  It'd be kind of a lame fix (like commenting out javacript for really old browsers), but it'd work.

CUE files are unoptimal

Reply #2 –
they do, foobar writes RG to them:

Code: [Select]
PERFORMER "Elton John"
TITLE "11-17-70"
REM REPLAYGAIN_ALBUM_GAIN -6.9700 dB
REM REPLAYGAIN_ALBUM_PEAK 0.9839
FILE "11-17-70.flac" WAVE
  TRACK 01 AUDIO
    TITLE "Bad Side of the Moon"
    PERFORMER "Elton John"
    INDEX 01 00:00:00
    REM REPLAYGAIN_TRACK_GAIN -7.1300 dB
    REM REPLAYGAIN_TRACK_PEAK 0.9825
  TRACK 02 AUDIO
    TITLE "Amoreena"
    PERFORMER "Elton John"
    INDEX 00 04:59:60
    INDEX 01 04:59:62
    REM REPLAYGAIN_TRACK_GAIN -6.2300 dB
    REM REPLAYGAIN_TRACK_PEAK 0.9646
"You have the right to remain silent. Anything you say will be misquoted, then used against you."

CUE files are unoptimal

Reply #3 –
Then I guess maybe we should try to convince Peter to add meta-data stuff.  Actually, I've got exactly one cue file (hand written, took a while, seeking and finding the best spots to split the tracks) so it doesn't really affect me one way or the other.

CUE files are unoptimal

Reply #4 –
yeah cue's do allow comments, you just have to add REM to the beginning, if you use CueMaster it will add:

Quote
REM ** Generated by CueMaster v1.6 **
REM Time  : 73:03:00
REM Length: 4383 seconds
REM Year  : 2002
REM Genre : Euro-House
REM DiscID: c0111d1d


so if peter wants to implement it he should go for it, it would do the job fine!

CUE files are unoptimal

Reply #5 –
Quote
I made a post in a previous topic about CUE files. They could be replaced rather easily with a superior format. Presently, CUE files do not store meta-data. This is a little frustrating to people who don't desire to use the database, as they can't really edit the information. There are also seeking problems associated with CUE files and huge files in certain cases. An alternative to a CUE file could implement a seek-point measured in bytes to end the "slow seek times" complaint. I am unsure whether or not there exists a superior format, but by simply changing from CUE to something a little more advanced, you could kill two semi-bugs with one plugin/extension.

Now, anyone interested?

If you are looking for superior format then Matroska can do everything what you need and more. Also, Matroska will be the container format for Musepack SV8 when it's ready.

Public beta was just released and news about it is on Hydrogen Audio frontpage:
http://www.hydrogenaudio.org/forums/index....t=ST&f=2&t=8900

CUE files are unoptimal

Reply #6 –
A nice solution would be to use Ape tags to store cue info. This way you can get rid of the cue and avoid to see a double file (the audio one usually untagged) while you use commands like "add Directory".

the CAS

CUE files are unoptimal

Reply #7 –
Quote
If you are looking for superior format then Matroska can do everything what you need and more. Also, Matroska will be the container format for Musepack SV8 when it's ready.
Public beta was just released and news about it is on Hydrogen Audio frontpage:
http://www.hydrogenaudio.org/forums/index....t=ST&f=2&t=8900

I dont think matroska can be what these people want, i guess they are more interested to adding external meta-seek tables to existing files. But it could be worthwhile to look at matroska's CUE tables as a Guideline, and maybe even some code from libmatroska could be used ( with robux4' permission ). Code from VdubMod or mkvmerger could be a good example of how to parse WAV files, mux them into matroska files and write CUE tables accordingly .....

CUE files are unoptimal

Reply #8 –
Quote
A nice solution would be to use Ape tags to store cue info. This way you can get rid of the cue and avoid to see a double file (the audio one usually untagged) while you use commands like "add Directory".

the CAS

APE tags do not support storing data for multiple songs, and sticking multiple tags on one file is not a pretty solution.

CUE files are unoptimal

Reply #9 –
Well, APE tags don't willingly support multiple tracks.  But it's possible.

__TRACKNUM
__TRACK_X_BEGINPOS
__TRACK_X_ENDPOS // maybe leave this one out
__TRACK_X_AUTHOR
__TRACK_X_TITLE
__TRACK_X_ORIGINAL_TRACKNUMBER
__TRACK_X_replaygain_album_peak

etc.

It's not a pretty solution, though, and I don't think Peter wouold be interested in bastardizing the standard like that.

CUE files are unoptimal

Reply #10 –
Well, I don't think this will lead to a format "bastardization" because:
1) CUE format  itself it's not a widespread standard (even Winamp requires a plugin to handle it) and a pseudo playlist with the Comments(rem) hack it's not a clean solution either.
2) The flexibility of Ape tags easily allows that.

The advantages of the Cue-inside-tags method are:
1) When you tag or rename you have to modify a single file
2) Other tag formats would allow this method (the evil ID3v2 Tags, ogg tagging format...)
3) Fewer issues on the programming side.

the CAS

CUE files are unoptimal

Reply #11 –
I vote for APEv2 and Vorbis Comment support
(even if non-standard)

A standard solution (like matroska) is of course preferred (by some),
but file sharing guys wouldn't like files wrapped in some unknown container.
ruxvilti'a

CUE files are unoptimal

Reply #12 –
Quote
I vote for APEv2 and Vorbis Comment support
(even if non-standard)

A standard solution (like matroska) is of course preferred (by some),
but file sharing guys wouldn't like files wrapped in some unknown container.

Myself, I think it's time to deprecate the CUE format. In its present form, it can't accurately reproduce certain situations like say, CloneCD can, nor can it hold meta-data without commenting hacks. Maybe switch to some XML based format? The problem is that CUE is too well-known already. It's format shouldn't be too difficult to extend, though. I don't know if CUE file readers would accurately ignore additional data inserted using non-standard tags.

I don't like the tagging solution. Tagging is made for information about the production of the file, not playback information. Even storing replaygain info there is a little bit of a kludge (although I appreciate it). Cluttering it up with several hundred more tags to allow it to store unique information about tracks would be downright ugly.

I think the best solution would be to replace the CUE file itself with a file of alternate formatting. Whether to extend the CUE format itself or create something new should be where the debate is. Wrapping the files in a container could work for some applications as well, but at the cost of compatibility.

CUE files are unoptimal

Reply #13 –
The purpose of CUE-files is to describe the track layout of a CD, not to store meta data about the file(s) created from the data on the CD, so I think a new format is preferable.

Quote
1) CUE format itself it's not a widespread standard (even Winamp requires a plugin to handle it) and a pseudo playlist with the Comments(rem) hack it's not a clean solution either.


Yes, it is very widespread when used for its true purposed.

CUE files are unoptimal

Reply #14 –
Yes, but how to convince people/developers to use/support this format?
ruxvilti'a

CUE files are unoptimal

Reply #15 –
Quote
Yes, but how to convince people/developers to use/support this format?

I never said I wanted it to be used beyond FB2K. I'd be happy with a stable meta-data storing format that works only with foobar. I'm sure that if it's decently done (and knowing Peter if he did it, it would have to be to be released) it'll catch on elsewhere.

Edit: I know it's cliche, but could XML work here? 

CUE files are unoptimal

Reply #16 –
I don't know why everyone is so orgasmic about XML.  It's useful in some ways, for some things, but I think it's way overused.  It's often just an overly-complicated way of doing simple things.

CUE files are unoptimal

Reply #17 –
Quote
I don't know why everyone is so orgasmic about XML.  It's useful in some ways, for some things, but I think it's way overused.  It's often just an overly-complicated way of doing simple things.

It depends on what your goals are for data storage.

I think the real strengths of XML lie in the ability to validate and check for well-formedness (this goes a long way towards enforcing best practices, cutting down on error handling madness, etc), the inherint transformability of the system, the seperation of content from formatting, and namespaces/extensibility/modular structure.  I often seem to find that the people that complain the most about XML simply don't understand how to use it very well, or don't understand what it was designed to do.

At any rate, some of these things wouldn't be of much use, but some certainly would be.  You could write a nice DTD or preferrably a Schema for such a format and be relatively sure that it would cut down on the amount of people implementing support in a broken manner due to non-standard formatting.  One of the big advantages here is that a Schema would be self-documenting as to the allowed structure of the document, instead of being tied to sourcecode or some other vague or hard to understand description.  You could also break down different types of metadata support into different modules which would be good for foward compatibility, making the format easily extensible to support new data as needed (the lack of which seems to be kind of the problem being discussed here with the CUE format).

To respond to Canar, XML shouldn't be the method here so much as the form.  The real issue would be in deciding upon the structure and purpose of a new format, not necessarily the way it is marked up.

CUE files are unoptimal

Reply #18 –
*grin* Contrary to how my last post sounded, I do understand how to implement things in XML. I've read through or gotten the jist of most of the W3C recommendations. The XML thing was more a joke than anything, but I think that the concept does have its merits. You explain them very succinctly, Dibrom.

The key problem I see is that the meta-data being stored doesn't have much of a tree-leaf structure. The data itself seems to be flatter. There's standard meta-data (foobar presently makes no distinction other than just "editable meta-data" and "non-editable meta-data"), and there'd be possibly input format data, referring to the structure of the CD with tracks and pre-gaps, then the seek data, which could probably be lumped in with the input format data. There would be one set of meta-data for the single-file album, and one set for the CUE-file individual tracks. Gah. I hope that all made sense.

At the individual meta-datum level, there would be few/no tags allowed inside the meta-data tag. The application itself doesn't seem to require the robustness of XML. We're not dealing with anything that complex....

CUE files are unoptimal

Reply #19 –
Quote
You could write a nice DTD or preferrably a Schema for such a format and be relatively sure that it would cut down on the amount of people implementing support in a broken manner due to non-standard formatting.

Now this is a valid reason to use XML.  I'm not opposed to XML by any means.  I think it definitely has uses, but if you ask enough people, there'll be someone who thinks XML should be used for everything, and that I disagree with.