FLAC choices

[radish]

I'm trying some tests of my own, and the first odd thing I noted, is
there seems to be some transcoding going on, when I'm streaming a flac
file to an SBR. Can that be right?

When playing a single-file&cue FLAC the server uses transcoding to split out the individual tracks for playback (the player itself doesn't understand cue sheets). It's all lossless, so only an issue if you lack server resources.

[cdmackay]

radish wrote:
> When playing a single-file&cue FLAC the server uses transcoding to
> split out the individual tracks for playback (the player itself doesn't
> understand cue sheets).

oh! that never occurred to me, thanks much.

cheers,
calum.

[cdmackay]

I've spotted another slight oddity when using flac file-per-CD + cue,
and wondered if it is just my ripping/tagging at fault.


In my first test, I ended up with a flac file containing just one tag,
ALBUM, in the VORBIS_COMMENT block.

SC happily took the PERFORMER tag, and the per-track TITLE tags, from
the cuesheet file, but took the ALBUM tag from the flac file's
VORBIS_COMMENT block, and ignored the main TITLE tag in the cuesheet file.


For the second test, I removed the ALBUM tag from the flac file's
VORBIS_COMMENT block, leaving no tags in the flac file.

SC, as before used PERFORMER & per-track TITLE tags, and continued to
ignore the main TITLE tag, from the cuesheet file. Since there were no
tags in the flac file itself, this resulted in SC saying "no album".


Is this expected? Does SC not use the main per-album TITLE tag in the
cuesheet file?


I did note that the cue file, apparently a text file, actually starts
with the UTF-8 BOM marker* (0xEFBBBF) before the word TITLE, and perhaps
this is interfering with the SC scanner's attempts to read the line?

I will try again, with those initial 3 bytes removed, and see if SC now
groks the first per-album TITLE flag.


cheers,
calum.

http://en.wikipedia.org/wiki/Byte-order_mark

[chill]

Calum

I'd hazard a guess that that odd character could be to blame. SC seems to have no trouble taking the "TITLE" tag from my CUE sheets. Before any of the track information in my CUE sheets I have "PERFORMER", "TITLE" and "FILE" tags (as well as a few "REM" comments), and all seem to be understood. I recently stripped all the tags from my FLAC files to avoid any possible clashes or confusions, but even before then I hadn't experienced any problems.

I look forward to the result of your testing without that character.

[cdmackay]

chill wrote:
> I look forward to the result of your testing without that character.

thanks.

And indeed, that was the problem.

I removed the 3-byte UTF-8 BOM - which is redundant on a modern UNIX
system anyway - form the cue file, and now SC finds and correctly uses
the per-album TITLE tag.

So that's all working perfectly.

On a related note: is there a list of what tags are recognised when
viewing a cue sheet?

I know of the table of recognised tags in the wiki, but it does not
mention CUE sheet files, and in fact does not mention the PERFORMER tag,
which makes me wonder whether other tags are allowed.

I do see the replaygain tags as REM comments; what else is/isn't allowed?

thanks much,

cheers,
calum.

[Moonbase]

Currently, these should be recognised in a CUE sheet (as per SC 7.4-25416):

• For the MAIN entry (these must not have leading whitespace!):
  
  • TITLE
  • PERFORMER
  • REM YEAR
  • REM GENRE
  • REM DISC
  • REM DISCC
  • REM COMMENT
  • REM DATE (for EAC — uses DATE instead of YEAR)
  • REM REPLAYGAIN_ALBUM_GAIN
  • REM REPLAYGAIN_ALBUM_PEAK
  • FILE
• For the single TRACK entries (these must have leading whitespace!):
  
  • TRACK xx AUDIO
  • TITLE
  • PERFORMER
  • REM REPLAYGAIN_TRACK_GAIN
  • REM REPLAYGAIN_TRACK_PEAK
  • REM YEAR
  • REM GENRE
  • REM COMMENT
  • REM COMPOSER
  • REM CONDUCTOR
  • REM BAND
  • REM DISC
  • REM DISCC
  • INDEX 00 (for Pre-Gap)
  • INDEX 01
  • (Warning: INDEX 02 and following will not be recognized!)
  • REM END (track end position; if given, overrides what can be calculated from file or next index/track; ideally be used for the "hidden track" case where you can have many minutes of silence in a track; format: "mm:ss:ff" [a "frame" is 1/75 second])

Note: In theory, all of above starting with "REM" could be used without the REM and SC would still understand them. Nevertheless, I’d advise against doing that, since it might break compatibility of your CUE sheet with other software.


If any of the following are not in the Cue Sheet, SC will try to get the information from the actual file tags:

• ARTIST
• ALBUM
• YEAR
• GENRE
• REPLAYGAIN_ALBUM_GAIN
• REPLAYGAIN_ALBUM_PEAK

[cdmackay]

that's wonderful, exactly what I needed, and more

thanks very much, Moonbase,

cheers,
calum.

[cdmackay]

Moonbase wrote:
> Currently, these should be recognised in a CUE sheet:
>
> - For the single TRACK entries (these -must- have leading
> whitespace!):
>
> - REM TITLE -(seems a bug to me, shouldn’t it be TITLE
> only?)-

I can confirm that "TITLE" alone (i.e. as opposed to "REM TITLE") works
fine in a "TRACK xx AUDIO" block, at least with my SC (7.4-25367).

thanks again.

cheers,
calum.

[cdmackay]

radish wrote:
> When playing a single-file&cue FLAC the server uses transcoding to
> split out the individual tracks for playback (the player itself doesn't
> understand cue sheets).

This seems, to me, like it might be the biggest (perhaps only real)
drawback of single file-per-CD flac + separate cue.

Having to decompress/decode to WAV, to extract the track needed, then
recode it back to FLAC again, albeit at the lowest/fastest compression
level, seems rather wasteful.


Presumably, when using file-per-track flac, the file is just streamed
directly to the Squeezebox, without any transformation whatsoever?


thanks,
calum.

[Moonbase]

I’ll check the code again, thanks for trying.

Glad that I could be of help :-)

EDIT: You’re absolutely right. All above starting with "REM" could actually be used without "REM", though I advise against doing that since it might break compatibility of your CUE sheet with other applications. I’ll edit above post so we have one post that explains it all.

Cheers again.