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?

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.

they do, foobar writes RG to them:

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.

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



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

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

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

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 .....

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

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.

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

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.

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.



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

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?

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.

*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....

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.