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: Standard for Extended Cuesheet Info (Read 5104 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Standard for Extended Cuesheet Info

I've been talking to Irage, who developed the handy CDi2MP3 tool (http://c2m.irage.org/), and have asked him to add in support for extended cuesheet information (like if you have a different Genre or Year for each song REMed into the cuesheet.

Irage was wondering if there was some kind of official RFC, or standard documented somewhere for how this information is embedded into the cuesheet, so that he could make sure that his program parsed the information properly.

Is there anyone that knows of such a thing?  I've sent a message off to WigBaM already, whe wrote the foo_cue_ex module that allows foobar to handle extended cuesheet information in this manner.

I know that in his program, it's very simply a line that looks like:
REM genre F DANCE
REM date 1994
REM bpm 135

No quotes or anything... and I'm guessing it's pretty arbitrary as to what types of fields could be stored, as long as they don't have spaces in them (i.e. not "beats per minute".

Anyone with some info about cuesheets and all this, who could point me to some "official" documentation, should any exist, would be much appreciated.

Standard for Extended Cuesheet Info

Reply #1 –
I was looking for similar documentation some time ago to add extended cue sheet metadata to slim devices' slimserver. I couldn't find any then so I settled for

REM GENRE "Classical"
REM YEAR "2000"
REM COMMENT "Foo"

I'm not sure what this has to do with lossless codecs though.

Standard for Extended Cuesheet Info

Reply #2 –
Thanks for the reply jth.

As for lossless codecs... this is the closest section I could find.  A lot of people use cuesheets when taking lossless CD images, so that's the relationship (in my mind, at least).

I noticed that you quoted your fields, which is what I would have done, if I had implemented it, but apparently WigBam didn't agree.

It just dawned on me that the slimserver supports cuesheets... that's cool! I didn't know that.  What would happen if you used cuesheets on the slimserver that did NOT have quotes, like wigbam's extended cuesheets?

Can it still parse them okay?

Standard for Extended Cuesheet Info

Reply #3 –
Slimserver requires the quotes to parse the extended cuesheet metadata.

Standard for Extended Cuesheet Info

Reply #4 –
jth: have you (or anyone else) put together a guide for what is and is not legal in an extended cuesheet vis a via slimserver?  I know I'm putting in a ton of time trying to write tools that will allow me to embed cuefiles in whole-album flacs in anticipation of slimserver 6 and squeezebox2.  Some guidlines from you guys who actually write the perl code would be VERY helpful!

Standard for Extended Cuesheet Info

Reply #5 –
The guide is the source code. Note that embedded cuesheet processing is totally different than external cuesheet processing.

embedded cuesheet processing has had problems in slimserver 5 - hopefully it will be sorted out by slimserver 6. External cuesheets have had better luck.

slimserver 6 supports no less than 6 different methods to retreive tags from embedded cuesheets. Look for the subroutine getSubFileTag() in the FLAC.pm file. Methods as preferred by the author of FLAC.pm (not me) are listed from top to bottom.

Sorry I can't give more explicit guidelines, but they would probably be out of date very quickly.

Standard for Extended Cuesheet Info

Reply #6 –
Quote
The guide is the source code.
[a href="index.php?act=findpost&pid=281920"][{POST_SNAPBACK}][/a]


Being someone who hasn’t written code seriously for the past 10 years, and back then, only being fluent in C, I have a hard time following the perl code.  I’m not seeing anything that seems to require that track CD_TEXT keywords (e.g. GENRE, PERFORMER, YEAR, COMMENT) need to be prefixed with a “REM “ as you seemed to indicate in your previous post.  I do see, as you said, that the data following the keyword needs to be quoted (e.g. YEAR “1980”) in order for the tag to be picked up, even though the CD_TEXT regs don’t call for quotes when the data doesn’t contain spaces.  Oh, well, I can live with that.

I thought that Slimserver 6, with it’s SQL back-end, was supposed to allow more flexibility in tagging.  However, from looking at the perl code, it looks as though CD_TEXT tags like COMPOSER or ARRANGER will be ignored, at least when flac-embedded cuesheets are scanned.

I know that this is going to sound whiney, but I’ve got to say this:  I don’t believe that the best documentation is ever the code.  I think this tends to lead to a situation where “whatever the code does” becomes the expectation of “what the code ought to do.”  You end up with no basis to judge if the code is working properly.

In my case, I’ve got a couple of thousand of classical CDs to encode to whole-album FLACs and tagging them all isn’t going to be trivial.  It would be nice to see some guidance from the guys actually writing the code.  As it is, I’m sure I’ll be performing a lot of trial and error testing before I’m able to settle on a personal “standard” that happens to work with SlimServer and the other apps need to look at cuesheets (cue2toc, cdrdao, etc.)

On a positive note, it is nice to see SlimServer 6 able to handle UTF8 encoded tags in flac files.

Standard for Extended Cuesheet Info

Reply #7 –
Quote
Being someone who hasn’t written code seriously for the past 10 years, and back then, only being fluent in C, I have a hard time following the perl code.  I’m not seeing anything that seems to require that track CD_TEXT keywords (e.g. GENRE, PERFORMER, YEAR, COMMENT) need to be prefixed with a “REM “ as you seemed to indicate in your previous post.  I do see, as you said, that the data following the keyword needs to be quoted (e.g. YEAR “1980”) in order for the tag to be picked up, even though the CD_TEXT regs don’t call for quotes when the data doesn’t contain spaces.  Oh, well, I can live with that.


For the REM issue, I was referring to the code that parses a separate .cue file. The embedded cuesheet parsing is different. I don't use embedded cuesheets for FLAC files on slimserver so I'm not familiar with that part of the code - I just know where it is.

Quote
I thought that Slimserver 6, with it’s SQL back-end, was supposed to allow more flexibility in tagging.  However, from looking at the perl code, it looks as though CD_TEXT tags like COMPOSER or ARRANGER will be ignored, at least when flac-embedded cuesheets are scanned.


The groundwork has been laid, but no additional work has been done here. You may be interested that there was a small email thread on the slim-users mailing list regarding classical music tagging standards and possible improvements to the server. There was interest but no-one took the lead in publishing a standard or writing code.

Quote
I know that this is going to sound whiney, but I’ve got to say this:  I don’t believe that the best documentation is ever the code.  I think this tends to lead to a situation where “whatever the code does” becomes the expectation of “what the code ought to do.”  You end up with no basis to judge if the code is working properly.


I didn't say that code was the best documentation - but it is all that exists.

Quote
In my case, I’ve got a couple of thousand of classical CDs to encode to whole-album FLACs and tagging them all isn’t going to be trivial.  It would be nice to see some guidance from the guys actually writing the code.  As it is, I’m sure I’ll be performing a lot of trial and error testing before I’m able to settle on a personal “standard” that happens to work with SlimServer and the other apps need to look at cuesheets (cue2toc, cdrdao, etc.)


I'm in the same boat. Right now you are pretty much limited to COMPOSER, CONDUCTOR and BAND (for regular flac tags, not embedded). There are a lot of things that I'm not sure about - for instance if you would like to include additional performers, should you use multiple ARTIST tags or one ARTIST tag with separators (the slimserver supports arbitrary separators in the ARTIST tag). Tagging classical music is hell. Good luck!

I'd recommend joining the slim-users mailing list - if you have any ideas or criticisms please post there. By the way, I'm not a slimserver developer, I just contribute little bits and pieces here and there.

By the way, people seem to get all worked up about single file FLAC nirvana (including myself in the past). At the end of the day, the music sounds the same and there is greater software compatibility using 1 FLAC file per track - so that's what I use with slimserver. Please - no flaming - I'm well aware of the pros and cons of each method.
 

Standard for Extended Cuesheet Info

Reply #8 –
Man, sometimes I really wonder why I ended up ripping all my CDs into single file apes, because it sure did make my life  a lot more complicated.  In any case, I'm happy with WigBam's plugin for foobar2000 because it allows me to do everything that I need to do. (namely transcoding to other formats and splitting up my single-file CD rips into multi-file tracks while adding tags for BPM, genre, and date).

What I'm not so happy about was finding out that WigBam's method and yours seem to be incompatible.  The main difference being that you quoted your data, and capitalized your field types, making it look more like the "standard" cuesheet items.  WigBam didn't.  The advantage (that I see) of that, I suppose, is that you can more easily have double quotes in your data... if you need double quotes in a composer name, or something, I guess.  The problem is that if you are using quoted data with WigBam's foobar component, you get the extra quotes in all your tag information at no extra charge.

Is there a way that some kind of a standard for this could be proposed, and even adopted more universally?  Maybe I'm the only one who actually would see any point in this...