Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27
  1. #11
    Senior Member
    Join Date
    Oct 2006
    Location
    sheffield, uk
    Posts
    406
    Quote Originally Posted by Gazjam View Post
    no, no, no, no, no.
    Built one and all the faffing about with linux aside, sound quality isn't quite there yet.

    Big computer audio guy here, if it was better I'd be using one!
    Depends what you use for output, my Pi has nothing to do with it, just an I2C S/P-DIF out.

    It also takes sod all technical knowledge.

    Burn SD card image
    Put in raspberry Pi
    Follow simple instructions on picoreplayer site.

    Done.

  2. #12
    Senior Member Julf's Avatar
    Join Date
    Dec 2010
    Posts
    2,451
    Quote Originally Posted by Gazjam View Post
    Built one and all the faffing about with linux aside, sound quality isn't quite there yet.
    Even when using an external DAC?
    "To try to judge the real from the false will always be hard. In this fast-growing art of 'high fidelity' the quackery will bear a solid gilt edge that will fool many people" - Paul W Klipsch, 1953

  3. #13
    Senior Member Wombat's Avatar
    Join Date
    Feb 2006
    Posts
    1,120
    Quote Originally Posted by probedb View Post
    That's really odd. The compression has no effect on decompression time for FLAC afaik. If you use a higher number to compress it doesn't make it any more difficult to decompress.

    Even my original Slim Devices SB3 has never once tripped on a single FLAC, 16/44.1 or 24/96 and they're all done -8.
    Unfortunately using higher compression adds slightly more stress on the Transporter that was imho false advertised. On a PC the small increase in decoding is hardly measurable but for the CPU and its decoder code with the Transporter it is on the edge.
    It can't decode 24/96 right. I had files stuttering especialy when using a blocksize of 4608 at -8. Reencoding the same file using a blocksize of 4096 at -8 helps. In theory for 24/96 a blocksize up to 16384 is valid. The Transporter already can't play files with a blocksize of 8192 at all.
    With something like default -5 all files play for sure though.
    Transporter (modded) -> RG142 -> Avantgarde Acoustic based 500VA monoblocks -> Sommer SPK240 -> self-made speakers

  4. #14
    Senior Member
    Join Date
    Mar 2008
    Posts
    500
    Quote Originally Posted by Wombat View Post
    Unfortunately using higher compression adds slightly more stress on the Transporter that was imho false advertised. On a PC the small increase in decoding is hardly measurable but for the CPU and its decoder code with the Transporter it is on the edge.
    This was also an issue in the early days of the Touch.

  5. #15
    Senior Member Archimago's Avatar
    Join Date
    Nov 2005
    Posts
    1,096
    Quote Originally Posted by Wombat View Post
    Unfortunately using higher compression adds slightly more stress on the Transporter that was imho false advertised. On a PC the small increase in decoding is hardly measurable but for the CPU and its decoder code with the Transporter it is on the edge.
    It can't decode 24/96 right. I had files stuttering especialy when using a blocksize of 4608 at -8. Reencoding the same file using a blocksize of 4096 at -8 helps. In theory for 24/96 a blocksize up to 16384 is valid. The Transporter already can't play files with a blocksize of 8192 at all.
    With something like default -5 all files play for sure though.
    Interesting comment Wombat.

    I've always just used -8 with dBPowerAmp for all my FLAC encodes and never had a problem with any of the SB devices (SB3/Boom/Radio/Transporter/Touch). I vaguely remember there may have been an issue with an old Transporter firmware but that was years ago... I've never played with block sizes however - was there much size saving going to 16K sizes?
    Archimago's Musings: (archimago.blogspot.com) A 'more objective' audiophile blog.

  6. #16
    Senior Member Wombat's Avatar
    Join Date
    Feb 2006
    Posts
    1,120
    The blocksize doesn't do much. It averages slightly smaller with 8k or 16k at high bitrates.
    For 16/44.1 a blocksize of 4096 even creates smaller files as the 4608 maximum at this rate.
    For compatibility reasons the official flac defaults to 4096 for all rates.
    I remember the 24/96 Rebecca Pidgeon sample once used as example to hickup Transporter playback had a blocksize of 4608. Reencoding it to 4096 made it play better. I don't know if i did write about it back then. I use 4096 for everything since.
    Transporter (modded) -> RG142 -> Avantgarde Acoustic based 500VA monoblocks -> Sommer SPK240 -> self-made speakers

  7. #17
    Senior Member Mnyb's Avatar
    Join Date
    Feb 2006
    Location
    Vństerňs Sweden
    Posts
    16,159
    Quote Originally Posted by probedb View Post
    That's really odd. The compression has no effect on decompression time for FLAC afaik. If you use a higher number to compress it doesn't make it any more difficult to decompress.

    Even my original Slim Devices SB3 has never once tripped on a single FLAC, 16/44.1 or 24/96 and they're all done -8.
    it is a cornercase probably even content dependent and also some flac decoders are not developed by the flac project itself and can use novel features .

    A couple of years ago users reported this and it helped by reflac to -5 . SB3 cant trip on 24/96 as the server downsample to 24/48 flac . this was only reported for 24/96 .

    Btw was it the OP that wanted to knwo where the gain settings where ?
    Attached Images Attached Images  
    --------------------------------------------------------------------
    Main hifi: Touch + CIA PS +MeridianG68J MeridianHD621 MeridianG98DH 2 x MeridianDSP5200 MeridianDSP5200HC 2 xMeridianDSP3100 +Rel Stadium 3 sub.
    Bedroom/Office: Boom
    Kitchen: Touch + powered Fostex PM0.4
    Misc use: Radio (with battery)
    iPad1 with iPengHD & SqueezePad
    (spares Touch, SB3, reciever ,controller )
    server HP proliant micro server N36L with ClearOS Linux

    http://people.xiph.org/~xiphmont/demo/neil-young.html

  8. #18
    Senior Member
    Join Date
    Jul 2008
    Posts
    677
    Thanks for the help guys, and some interesting info about Flac compression.
    I'll stick to server side processing I think, just to be sure.

    BTW daft quesion?
    In Advanced settings\File Types...
    Setting to Disabled means server side decoding, as opposed to Native, meaning decoded on teh TRansporter?


    Thanks, just checking.

  9. #19
    Senior Member
    Join Date
    Jun 2011
    Posts
    131
    Quote Originally Posted by Gazjam View Post
    no, no, no, no, no.
    Big computer audio guy here, if it was better I'd be using one no mistake.
    Well, I'm not "big", just rather tall and slim, but I doubt if size matters in technical facts. It should not matter, which code transforms flac to pcm,as long as it is correct. Nor should the protocol affect the resulting pcm stream. I don't hear any difference on my cubietruck if I output streams up to 24/96 to toslink/spdif or usb/asio. Coax spdif supports only streams up to 24/192 but no dsd neither does toslink/spdif. Conversion from dsd to pcm is doubtful, see these articles :

    http://www.audiostream.com/content/q...-loesch-amrifi
    http://www.audiostream.com/content/q...dum-pcm-vs-dsd

    I guess ( since I don't know which dac you are using) what you hear is a different implementation of spdif and USB in your dac or you simply have used a different dac for usb and spdif.

    The transporter is quite an old piece of hardware, it should rest in piece :-)

    Greets
    Christian

  10. #20
    Senior Member
    Join Date
    Jan 2009
    Location
    Los Angeles & London
    Posts
    784
    I'm just going back to the original post. Why would you go for a Transporter when you've come from a Touch? Especially if you're using a DAC.

    The Touch can output 24/192 over USB with the EDO application, which means you can get an asynchronous connection that will also allow you to stream DSD in DoP format.

    Aside from having a pretty box, this doesn't make any sense. The processor in the Transporter is marginal at being able to handle 24/96 content as has already been discussed, so it's always operating at or close to its limits with high resolution audio, and you've already said you have material that is beyond its capacity to start with.
    Receiver stuck at blue LED state after reboot? Please vote for bug 17462

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •