FLAC choices

[cdmackay]

Calum Mackay wrote:
> 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.

I've just logged a bug for this:

http://bugs.slimdevices.com/show_bug.cgi?id=11289

although perhaps bug is a little strong, as really the ripping app
shouldn't be creating an unnecessary BOM. but some apps don't give you
the choice (e.g. XLD) so it would be nice if SC just ignored it.

cheers,
calum.

[radish]

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.

That, and the tagging issues also being discussed, which come up more frequently for flac&cue because less people use them == less testing.

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

Indeed, assuming default settings. But the transcoding is pretty easy so most servers shouldn't be bothered much by it.

[cdmackay]

Calum Mackay wrote:
> 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.

This BOM was in a cuesheet generated by the Mac ripper XLD.

Its author tells me that the next update will include an option to
disable writing the BOM.

cheers,
calum.

[Moonbase]

Very good news for those who rip on the Mac!

[cdmackay]

I was just re-reading this topic, and I noted one comment I made that I
still don't understand:

Calum Mackay wrote:
> Might it be related to this snippet I see in the main window when a
> track is selected?
>
> Bitrate: 754kbps VBR (Converted to 705.6kbps ABR)


I notice the "converted" message for file-per-CD flac, but not for
file-per-track, I believe.

Would anyone be able to explain what this message is really telling me,
please?

thanks much,

cheers,
calum.

[Moonbase]

It just shows you the bitrate of your original (whole CD) FLAC (754kbps VBR) plus the bitrate of the "piece" it had to "cut" out of it (705.6kbps ABR) in order to send it to the player (which only understands single FLAC files, no cue sheets, so SC "snips" part of your whole CD file and sends it as a single FLAC to the player).

For simplicity, this is done using the standard SC transcoding mechanism, and thus can result in a different bitrate. Since FLAC is lossless, nothing bad will happen. :-)

The (relatively small) extra overhead for transcoding could be saved by using single-track FLACS, these can (usually) be sent directly to the player.

[cdmackay]

Moonbase wrote:
> It just shows you the bitrate of your original (whole CD) FLAC (754kbps
> VBR) plus the bitrate of the "piece" it had to "cut" out of it
> (705.6kbps ABR) in order to send it to the player (which only
> understands single FLAC files, no cue sheets, so SC "snips" part of
> your whole CD file and sends it as a single FLAC to the player).

ah of course, and I even knew that bit, just didn't put it together.

thanks much again

[cdmackay]

Calum Mackay wrote:
>> 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.
>
> This BOM was in a cuesheet generated by the Mac ripper XLD.
>
> Its author tells me that the next update will include an option to
> disable writing the BOM.


and that version has now been released: XLD 20090314.

cheers,
calum.

[cdmackay]

Calum Mackay wrote:
> Calum Mackay wrote:
>>> 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.
>> This BOM was in a cuesheet generated by the Mac ripper XLD.
>>
>> Its author tells me that the next update will include an option to
>> disable writing the BOM.
>
> and that version has now been released: XLD 20090314.

....which turned out to have a bug, meaning that the BOM was still
written. I ought to have tested before posting here, apols.

I reported it to tmkk, the author of XLD, who fixed it immediately. I
have tested the current version, XLD 20090315, and can confirm that it
now doesn't write a BOM unless you ask it to, and so its cue files are
now fully compatible with SC.

cheers,
calum.

[cdmackay]

So, it would appear that we're short of sorting tags, then? No way of
getting SC to sort by a different tag than e.g. Arist, when using a cue
file?

Is it worth logging an RFE to add support for e.g. REM ARTISTSORT, etc?

cheers,
calum.

Moonbase wrote:
> Currently, these should be recognised in a CUE sheet:
>
> - For the MAIN entry:
>
> - 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
> - PERFORMER
> - REM REPLAYGAIN_TRACK_GAIN
> - REM REPLAYGAIN_TRACK_PEAK
> - REM TITLE -(seems a bug to me, shouldn’t it be TITLE
> only?)-
> - 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)-
>
>
>
> 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
>
>