PDA

View Full Version : SqueezeBox 2, Slimserver 6 and FLAC question



Gordon Harris
2005-03-29, 16:20
My SqueezeBox2 arrived today. Lot's 'o fun so far. I do have a question about
the FLAC transport: no matter how I change the Server->File Types settings or
comment out lines in convert.conf, Slimserver still seems to transcode my
FLACs. Even with just FLAC (built-in) enabled, I'm seeing the following
process created by Slimserver on playback:

cmd.exe /x/d/c ""C:\Program Files\SlimServer\server\Bin\MSWin32-x86-multi-
thread\flac.exe" -dcs --skip=0:00.00 --until=5:02.24 --
"D:\Recordings\Music_FLAC\c_Early_Baroque\Biber, H\Missa Bruxellensis -
Savall.flac" | "C:\Program Files\SlimServer\server\Bin\MSWin32-x86-multi-
thread\flac.exe" -cs --totally-silent --compression-level-0 -"

To me, this looks as though the Slimserver requires flac.exe to stream to
stdout at compression level 0 to get FLAC content to the SqueezeBox2. The
above FLAC file was encoded at level 5. Even if I re-encode a FLAC at level 0
and play that, the "transcoding" FLAC | FLAC operation still takes place.

I know that when Slimserver streams MP3s to the SqueezeBox, nothing special
needs to happen (i.e. LAME isn’t required to be invoked.) Is this a case where
Slimserver doesn’t quite know how to parse and stream FLAC data directly yet?
Should we expect truly "native" FLAC streaming from a future version of
Slimserver?

This current arrangement for FLAC streaming works perfectly well. I just
assume that the two invocations of flac.exe aren’t doing anything that
Slimserver couldn’t do with a little more code tweaking. That would knock down
the CPU utilization a bit, knock down the temperature inside my media server
case, and maybe allow me to do with one less fan. But I can certainly live
with the current arrangement.

PS: The larger memory buffer in the SqueezeBox 2 is great. Even with
Slimserver scanning my music library, and with me browsing genre, I don’t get
any FLAC drop-outs. Also, FLAC play back seems to be perfectly gapless now.

Way to go, Slimdevices and Slimserver developers. You guys are awesome.

JJ
2005-03-29, 16:49
Is there anyhing you have to do in the player config to tell SlimServer
that it's feeding an SB2 instead of an SB1, or does the server figure it
out on its own?


----- Original Message -----
From: "Gordon Harris" <gharris999 (AT) earthlink (DOT) net>
To: <discuss (AT) lists (DOT) slimdevices.com>
Sent: Tuesday, March 29, 2005 4:20 PM
Subject: [slim] SqueezeBox 2, Slimserver 6 and FLAC question


> My SqueezeBox2 arrived today. Lot's 'o fun so far. I do have a
> question
> about the FLAC transport: no matter how I change the Server->File
> Types settings or comment out lines in convert.conf, Slimserver still
> seems
> to transcode my FLACs. Even with just FLAC (built-in) enabled, I'm
> seeing
> the following process created by Slimserver on playback:

vidurapparao
2005-03-29, 16:54
Gordon Harris wrote:

>My SqueezeBox2 arrived today. Lot's 'o fun so far. I do have a question about
>the FLAC transport: no matter how I change the Server->File Types settings or
>comment out lines in convert.conf, Slimserver still seems to transcode my
>FLACs. Even with just FLAC (built-in) enabled, I'm seeing the following
>process created by Slimserver on playback:
>
>cmd.exe /x/d/c ""C:\Program Files\SlimServer\server\Bin\MSWin32-x86-multi-
>thread\flac.exe" -dcs --skip=0:00.00 --until=5:02.24 --
> "D:\Recordings\Music_FLAC\c_Early_Baroque\Biber, H\Missa Bruxellensis -
>Savall.flac" | "C:\Program Files\SlimServer\server\Bin\MSWin32-x86-multi-
>thread\flac.exe" -cs --totally-silent --compression-level-0 -"
>
>To me, this looks as though the Slimserver requires flac.exe to stream to
>stdout at compression level 0 to get FLAC content to the SqueezeBox2. The
>above FLAC file was encoded at level 5. Even if I re-encode a FLAC at level 0
>and play that, the "transcoding" FLAC | FLAC operation still takes place.
>
>I know that when Slimserver streams MP3s to the SqueezeBox, nothing special
>needs to happen (i.e. LAME isn’t required to be invoked.) Is this a case where
>Slimserver doesn’t quite know how to parse and stream FLAC data directly yet?
>Should we expect truly "native" FLAC streaming from a future version of
>Slimserver?
>
>This current arrangement for FLAC streaming works perfectly well. I just
>assume that the two invocations of flac.exe aren’t doing anything that
>Slimserver couldn’t do with a little more code tweaking. That would knock down
>the CPU utilization a bit, knock down the temperature inside my media server
>case, and maybe allow me to do with one less fan. But I can certainly live
>with the current arrangement.
>
>PS: The larger memory buffer in the SqueezeBox 2 is great. Even with
>Slimserver scanning my music library, and with me browsing genre, I don’t get
>any FLAC drop-outs. Also, FLAC play back seems to be perfectly gapless now.
>
>Way to go, Slimdevices and Slimserver developers. You guys are awesome.
>
>

The FLAC->FLAC transcoding is only done when you use cuesheets. To get
to a track start point within a FLAC file, we need to be able to seek to
the exact point in the file (actually to the exact frame that starts
before the cue point and then we may need to throw out some samples).
Obviously the FLAC decoder on the device can't seek through the stream
across a network for each song, so this seeking needs to be done on the
server side. Rather than do the seek in Perl, we use the flac helper
application with the --skip and --until parameters to provide us with
the exact samples to play and then recode in FLAC. It requires a little
CPU, but it's a lossless transcoding, of course.

The transcoding does not happen if you don't use cuesheets with FLAC
(excuse the double negative).

--Vidur

Daryle A. Tilroe
2005-03-29, 17:08
Vidur Apparao wrote:

> The transcoding does not happen if you don't use cuesheets with FLAC
> (excuse the double negative).

Hah. Another good reason to not to rip your CDs to one FLAC file!
I knew we track folk would be vindicated. ;-)

--
Daryle A. Tilroe

Gordon Harris
2005-03-29, 18:24
Vidur Apparao <vidur@...> writes:

> The transcoding does not happen if you don't use cuesheets with FLAC
> (excuse the double negative).

Excused. When you say "cuesheet," do you refer to the formal FLAC cuesheet
metadata block, or to the informal "cuesheet text file stuffed into a vorbis
comment" type of embedded cuesheet? If the former, then I guess it doesn't
matter what sort of metadata one tags the FLAC file with: embedded cue,
embedded xml, cddb record or "stacked" vorbis comments -- any "whole-disc" flac
file with a flac generated cuesheet block will need to be transcoded.

Rats. And here I've spent 2 months working on cuesheet parsing routines so as
to better tag whole-disc flacs. Now, it really does seem that there is an
advantage to single-track flac rips. Eh.

JJ
2005-03-29, 18:40
----- Original Message -----
From: "Gordon Harris" <gharris999 (AT) earthlink (DOT) net>
To: <discuss (AT) lists (DOT) slimdevices.com>
Sent: Tuesday, March 29, 2005 6:24 PM
Subject: [slim] SqueezeBox 2, Slimserver 6 and FLAC question


> Rats. And here I've spent 2 months working on cuesheet parsing routines
> so as
> to better tag whole-disc flacs. Now, it really does seem that there is
> an
> advantage to single-track flac rips. Eh.


What's the advantage other than slightly lower server load?

Is there any control over the level of compression to be used in this
transcoding? There's obviously a tradeoff between CPU load used to
transcode and the bandwidth used to stream the flac, so it seems there
should be a means of letting the user determine the level and perhaps
trade CPU cycles for lowered bandwidth.

vidurapparao
2005-03-29, 18:47
JJ wrote:

> ....
> Is there any control over the level of compression to be used in this
> transcoding? There's obviously a tradeoff between CPU load used to
> transcode and the bandwidth used to stream the flac, so it seems there
> should be a means of letting the user determine the level and perhaps
> trade CPU cycles for lowered bandwidth.

There is currently no UI to change the settings, but the compression
level can be changed by editing your convert.conf file. The entry for
flc-flc-transcode-* is the one that applies to this type of transcoding.

--Vidur

Gordon Harris
2005-03-29, 18:58
JJ <jj@...> writes:

>
> ----- Original Message -----
> From: "Gordon Harris" <gharris999@...>
> To: <discuss@...>
> Sent: Tuesday, March 29, 2005 6:24 PM
> Subject: [slim] SqueezeBox 2, Slimserver 6 and FLAC question
>
> > Rats. And here I've spent 2 months working on cuesheet parsing routines
> > so as
> > to better tag whole-disc flacs. Now, it really does seem that there is
> > an
> > advantage to single-track flac rips. Eh.
>
> What's the advantage other than slightly lower server load?
>
> Is there any control over the level of compression to be used in this
> transcoding? There's obviously a tradeoff between CPU load used to
> transcode and the bandwidth used to stream the flac, so it seems there
> should be a means of letting the user determine the level and perhaps
> trade CPU cycles for lowered bandwidth.
>

Actually, what they've done (transcoding to compression level 0) should
minimize the CPU load (as long as this transcoding has to be done anyway.)
Plus, the increased bandwidth needed for level 0 (lowest) compression is pretty
minimal: A typical whole-disc flac file compressed at level 5 (the FLAC
default) weighs in at 282,029 kb, and the level 0 version weighs in at 291,138
kb. That's an increase of, what? 3% or so? Doesn't seem like a big deal. I
can't imagine ever wanting to exercise the CPU more just to see a 3% drop in
bandwidth usage. But in terms of control over the process, you could try
editing the appropriate line in convert.conf and see what happens.

Daryle A. Tilroe
2005-03-29, 19:08
Daryle A. Tilroe wrote:
> Vidur Apparao wrote:
>
>> The transcoding does not happen if you don't use cuesheets with FLAC
>> (excuse the double negative).
>
>
> Hah. Another good reason to not to rip your CDs to one FLAC file!
> I knew we track folk would be vindicated. ;-)
>

Quick followup: Does this also then mean that track based FLACs
will support FF/REW within the track whereas the transcoded
CUE sheet based ones won't?

--
Daryle A. Tilroe

michael
2005-03-29, 21:57
"Daryle A. Tilroe" <daryle (AT) micralyne (DOT) com> writes:
> Vidur Apparao wrote:
>
>> The transcoding does not happen if you don't use cuesheets with FLAC
>> (excuse the double negative).
>
> Hah. Another good reason to not to rip your CDs to one FLAC file!
> I knew we track folk would be vindicated. ;-)

Yes, but before long I suspect there will be a 6.x slimserver.
Enjoy your temporary vindication while you still can. ;)


-michael

--
"Those customers concealing rational certainties
must check them at the door"
-Alan Moore "the Moon and Serpent Grand Egyptian Theatre of Marvels"

Daryle A. Tilroe
2005-03-30, 08:36
Daryle A. Tilroe wrote:
> Daryle A. Tilroe wrote:
>
>> Vidur Apparao wrote:
>>
>>> The transcoding does not happen if you don't use cuesheets with FLAC
>>> (excuse the double negative).
>>
>> Hah. Another good reason to not to rip your CDs to one FLAC file!
>> I knew we track folk would be vindicated. ;-)
>>
>
> Quick followup: Does this also then mean that track based FLACs
> will support FF/REW within the track whereas the transcoded
> CUE sheet based ones won't?
>

Vidur? Sean?

--
Daryle A. Tilroe

seanadams
2005-03-30, 08:39
On Mar 30, 2005, at 7:36 AM, Daryle A. Tilroe wrote:

> Daryle A. Tilroe wrote:
>> Daryle A. Tilroe wrote:
>>> Vidur Apparao wrote:
>>>
>>>> The transcoding does not happen if you don't use cuesheets with
>>>> FLAC (excuse the double negative).
>>>
>>> Hah. Another good reason to not to rip your CDs to one FLAC file!
>>> I knew we track folk would be vindicated. ;-)
>>>
>> Quick followup: Does this also then mean that track based FLACs
>> will support FF/REW within the track whereas the transcoded
>> CUE sheet based ones won't?
>
> Vidur? Sean?

I'm not ignoring the FLAC questions - I'm waiting for Vidur to wake up.
:)

One thought on this: if we find that CUEd FLACs are inherently just a
pain in the butt with no advantage in terms of gaplessness, would you
accept as a solution a script to unCUE them?

Daryle A. Tilroe
2005-03-30, 08:52
Sean Adams wrote:

>
> On Mar 30, 2005, at 7:36 AM, Daryle A. Tilroe wrote:
>
>> Daryle A. Tilroe wrote:
>>
>>> Daryle A. Tilroe wrote:
>>>
>>> Quick followup: Does this also then mean that track based FLACs
>>> will support FF/REW within the track whereas the transcoded
>>> CUE sheet based ones won't?
>>
>>
>> Vidur? Sean?
>
> I'm not ignoring the FLAC questions - I'm waiting for Vidur to wake up. :)
>
> One thought on this: if we find that CUEd FLACs are inherently just a
> pain in the butt with no advantage in terms of gaplessness, would you
> accept as a solution a script to unCUE them?
>

I think you have me confused with a CUE sheet fanatic. I'm a track man!
;-) I was just trying to confirm that since FLAC was native with the SB2
(ie. no transcoding) you could now FF/REW within a streaming FLAC track
file. I just wanted one more <Nelson>HA!HA!</Nelson> to rub in the faces
of the CUE sheet fanboys. :P :D

--
Daryle A. Tilroe

vidurapparao
2005-03-30, 09:03
Daryle A. Tilroe wrote:

> ...
>
>>
>> Quick followup: Does this also then mean that track based FLACs
>> will support FF/REW within the track whereas the transcoded
>> CUE sheet based ones won't?
>>
Yes, that is true for now. FFWD/REW is possible only for types that we
don't transcode - MP3 and FLAC without cuesheets for SB2. Pure PCM types
(wav and aiff) can be played at faster rates on SB2, but only if the
corresponding FLAC transcoding lines are removed from convert.conf.

--Vidur

Gordon Harris
2005-03-30, 10:24
Sean Adams <sadams@...> writes:

>
> One thought on this: if we find that CUEd FLACs are inherently just a
> pain in the butt with no advantage in terms of gaplessness, would you
> accept as a solution a script to unCUE them?
>


As a whole-disc/cue-embeded flac fan (I guess mostly because of my time
investment in the format) I can live with the current Slimserver transcoding
arrangement for the time being. I don’t think I’d use any sort of track-ifying
script, thank you.

But, in terms of the need to use flac.exe to transcode individual tracks from
flacs: I guess I’m just not getting what the problem is with writing the perl
code to seek to the appropriate place in a whole-disc/cue-embeded flac file.
(Forgive me if I’m speculating above my pay-grade here: I’ve never written a
single line of perl code.) If a flac file has a cuesheet-metadata-block, flac
version 1.1.2 allows one to use cuepoints to decode a portion of the flac
file. So, rather than using the "–skip=mm:ss.ss –until=mm:ss.ss" command line
form, one can use "–cue=n.n-n.n" to select a specific track/index range to
decode. I assume that this means that flac.exe isn’t having to use any sort
of "time to byte-offset" calculation to seek to the appropriate section of the
flac file. The cuesheet-metatdata-block includes sample offsets from the
beginning of the flac audio stream for each track and index in the cuesheet
metadata. Personally, I’ve never figured out how to convert a sample offset
into a byte offset, but, how hard could it be?

Sean? Vidor?

vidurapparao
2005-03-30, 10:48
Gordon Harris wrote:

> ....
>
>
>But, in terms of the need to use flac.exe to transcode individual tracks from
>flacs: I guess I’m just not getting what the problem is with writing the perl
>code to seek to the appropriate place in a whole-disc/cue-embeded flac file.
>(Forgive me if I’m speculating above my pay-grade here: I’ve never written a
>single line of perl code.) If a flac file has a cuesheet-metadata-block, flac
>version 1.1.2 allows one to use cuepoints to decode a portion of the flac
>file. So, rather than using the "–skip=mm:ss.ss –until=mm:ss.ss" command line
>form, one can use "–cue=n.n-n.n" to select a specific track/index range to
>decode. I assume that this means that flac.exe isn’t having to use any sort
>of "time to byte-offset" calculation to seek to the appropriate section of the
>flac file. The cuesheet-metatdata-block includes sample offsets from the
>beginning of the flac audio stream for each track and index in the cuesheet
>metadata. Personally, I’ve never figured out how to convert a sample offset
>into a byte offset, but, how hard could it be?
>
>
For FLAC embedded cuesheets, we should be able to get exact seekpoints
from the STREAMINFO header. This header is easily parseable in Perl - in
fact Michael Turner recently added seekpoint parsing code to our FLAC
formatting package. For external cuesheets, however, a
time-to-byte-offset calculation is necessary. This translation is fairly
hairy as it is (it involves an initial guess based on bitrate and then
frame parsing to find the exact point), and has the potential to be slow
in Perl. That being said, our longer term solution may be to implement
the seeking code entirely in Perl - it just hasn't happened yet.

--Vidur

Gordon Harris
2005-03-30, 11:21
Vidur Apparao <vidur@...> writes:

> For FLAC embedded cuesheets, we should be able to get exact seekpoints
> from the STREAMINFO header. This header is easily parseable in Perl - in
> fact Michael Turner recently added seekpoint parsing code to our FLAC
> formatting package. For external cuesheets, however, a
> time-to-byte-offset calculation is necessary. This translation is fairly
> hairy as it is (it involves an initial guess based on bitrate and then
> frame parsing to find the exact point), and has the potential to be slow
> in Perl. That being said, our longer term solution may be to implement
> the seeking code entirely in Perl - it just hasn't happened yet.

So...rather than calling FLAC to transcode to support external cuesheets, why
not call METAFLAC to embed the cuesheet? (just kidding..)