Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 28 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 278
  1. #21
    Senior Member
    Join Date
    May 2005
    Location
    UK
    Posts
    707
    Ok, I should probably sit down and think about this rather than posting on here, but it helps my thought process

    It appears that the conversion from a time to a sample number in the FLAC source assumes that the file is at 44100 Hz. I *think* that you can specify sample numbers in a cue sheet as opposed to times, in which case I can probably do the conversion myself (obviously using the correct sampling rate).

    I'll do some more digging into the cue sheet parsing code in the FLAC source to ensure I'm not doing anything stupid here.

    Andy

  2. #22

    Re: Playing AC3/DTS tracks sourced from DVD

    --- adhawkins <adhawkins.210sfz (AT) no-mx (DOT) forums.slimdevices.com> wrote:
    >
    > Ok, I should probably sit down and think about this rather than
    > posting
    > on here, but it helps my thought process
    >
    > It appears that the conversion from a time to a sample number in the
    > FLAC source assumes that the file is at 44100 Hz. I *think* that you
    > can specify sample numbers in a cue sheet as opposed to times, in
    > which
    > case I can probably do the conversion myself (obviously using the
    > correct sampling rate).


    in libFLAC you can only seek to a sample number, not
    a time point. with flac --skip and a time argument
    it converts time to sample number using the sample
    rate in the STREAMINFO block.

    AC3 is compressed and there is no direct correlation
    between time and the FLAC 'sample number', in fact, the
    FLAC 'sample number' only corresponds to an arbitrary
    position in the AC3 stream. the only reason AC3 can
    be fed to FLAC at all is because it is packaged in a
    WAV file to look like PCM samples, but it is really
    just chopped up compressed data. this is also why the
    FLAC compression ratio on it is so bad.

    if the WAV'ed AC3 stream is constant bitrate you can
    form an estimate of time to 'sample number'. if the
    padding is inserted non-uniformly then the estimate
    will be choppy. if the bitrate is not constant, all
    you can really assume is that a higher sample number
    corresponds to a later time.

    once you get an estimate of the target sample for a
    given time, the AC3 decoder make take some time to
    sync the stream again.

    Josh




    __________________________________________
    Yahoo! DSL ľ Something to write home about.
    Just $16.99/mo. or less.
    dsl.yahoo.com


  3. #23
    Senior Member
    Join Date
    May 2005
    Location
    UK
    Posts
    707
    I've done some more work on this, including automating the calculation of the seek points. It works (or at least be close enough for it to *appear* to work) so I think my method of manually calculating sample points is 'close enough'.

    I'll post the scripts when I've had chance to tidy them up, but they basically work for me (I've ripped 3 or 4 DVDs today with complete success).

    Andy

  4. #24
    Junior Member
    Join Date
    Oct 2005
    Posts
    26

    Playback of DTS on Squeezebox 1

    In your guide you mention that DTS-CDs are supported by the SB2 and SB3 without any tweaking, and mention also that the DTS/Surround files could be played back on a SB1 with some tweaking.

    I would really love to playback the 2 DTS discs I've got through the squeezebox 1 I've got, do you have any suggestions, as when I follow your instructions I just get noise, and my surround amp only detects a "stereo" output.

    Stephen.

  5. #25
    Senior Member
    Join Date
    Jun 2005
    Posts
    285
    Quote Originally Posted by eldebil
    My test was the following:
    software :
    ---16 mn of "Faithless - Live at Alexendra Palace" (DTS half rate )
    ...
    I wonder if the fact that it's half-bitrate is what's making it successful. My conversion utility pads DTS to a certain fixed size per frame, so a half-bitrate source file will contain more padding than a full-bitrate source and should therefore compress better with FLAC.

    When I look at the bitrate of one of my converted DTS files through SlimServer, I see "1535kbps CBR" -- a 48kHz WAV file is 1536 kb/s (that's kiloBITS per second) so that's just about as poor a compression as you can get. OTOH one of my AC3-FLAC files has a bitrate of about one third of that.

    If your Faithless track sounds fine, could you check the FLAC bitrate? I bet it's a fair amount lower than 1536 kb/s. If so, that seems to confirm my hypothesis that it's poor FLAC compression which is causing jerky playback.

    (OT: I borrowed that DVD last week and could have done my own test if I hadn't just given it back!)

    Thanks,
    Steve

  6. #26
    Senior Member
    Join Date
    Jun 2005
    Posts
    285
    Quote Originally Posted by sdevans
    In your guide you mention that DTS-CDs are supported by the SB2 and SB3 without any tweaking, and mention also that the DTS/Surround files could be played back on a SB1 with some tweaking.

    I would really love to playback the 2 DTS discs I've got through the squeezebox 1 I've got, do you have any suggestions, as when I follow your instructions I just get noise, and my surround amp only detects a "stereo" output.
    Assuming you've kept the data in a lossless format (eg FLAC; WAV is okay for this test actually as the music is at 44.1 kHz so Bug#128 is not an issue), and have followed all the guidelines on volume etc, all that's left is an SB1-specific conversion.

    IIRC the SB1 inverts the sign of each PCM sample it sends out; because we're using data disguised as PCM samples that inversion destroys the encapsulated data. I've asked about this before, and been given an answer, but I can't remember the exact details (so I may be wrong as to the precise nature of the inversion performed).

    What's needed is to process the data in your DTS-WAV file to flip the samples, before encoding to FLAC. Of course, that flipped data would only sound right when played through an SB1, which would flip it all back to the way it was intended to be; an SB2 would sound like noise.

    Somebody may have already written such a utility -- if not, and assuming I can get the proper details about the problem, it should be easy enough to write a Python script to deal with it.

    A better solution would be to not pre-process the data but come up with a small executable which could be added to the conversion pipeline for this specific file format. So your custom conversion config file would specify that when playing a file with extension 'dts-cd.flac' (say), it should pass it through untouched to an SB2 but decode to WAV and then flip the contents when the destination is an SB1.

    (Note that running a Python script as part of the conversion pipeline doesn't seem to be as easy as I previously hoped it would be, which is why it would be good if an actual binary executable could be found. If we can get those flip details and I knock up a small Python script, I'm sure a C programmer could easily translate it to something more directly executable.)

    So could anyone refresh my memory on the exact details of the SB1 problem? (Note that I don't have access to an SB1 so I can't test the output; I don't want to implement something based on a misinterpretation of the problem!)

    Cheers,
    Steve

  7. #27
    Senior Member
    Join Date
    Jun 2005
    Posts
    285
    Quote Originally Posted by Philip Meyer
    These posts seem pretty useful! Perhaps you could add them to the wiki at http://wiki.slimdevices.com for future reference?
    Good idea. I don't have the time right now; if anybody else wants to copy it over there then they're welcome. Can the wiki also host the utility zip file?

    If nobody else gets the chance to change the wiki, I'll try to make time myself in the future -- perhaps when any problems raised in this thread have been sorted out.

  8. #28
    Senior Member
    Join Date
    Jun 2005
    Posts
    285
    Quote Originally Posted by Josh Coalson
    AC3 is compressed and there is no direct correlation
    between time and the FLAC 'sample number', in fact, the
    FLAC 'sample number' only corresponds to an arbitrary
    position in the AC3 stream. the only reason AC3 can
    be fed to FLAC at all is because it is packaged in a
    WAV file to look like PCM samples, but it is really
    just chopped up compressed data. this is also why the
    FLAC compression ratio on it is so bad.

    if the WAV'ed AC3 stream is constant bitrate you can
    form an estimate of time to 'sample number'. if the
    padding is inserted non-uniformly then the estimate
    will be choppy. if the bitrate is not constant, all
    you can really assume is that a higher sample number
    corresponds to a later time.
    If the conversion utility is run with the --verbose option (somewhere before the input file name) then some debug data will give the AC3 frame size in bytes (eg "AC3 length: 14162397; frame length: 1792"). The conversion will pack each AC3 frame encountered into an IEC61937 frame of 6144 bytes; there's a one-to-one correlation between input and output frames. So if you (Andy) know which AC3 frame you want to cut on, you can work it out.

    (Note that each output frame in a converted DTS stream is padded to only 2048 bytes. I must confess that I couldn't find enough documentation to justify this; it was just the value that worked. I welcome any explanations or suggestions for improving that aspect!)

    Even if the AC3 file isn't of a constant bitrate, that frame correlation will hold true -- so if you're starting from an AC3 frame number you should be able to go on from there. Beware that the verbose output will only tell you the size of the first AC3 frame (just enough data to make a guess at the size of the padded output file so the WAV header can be written) so you can't use it to determine if the bitrate changes per frame.
    Quote Originally Posted by Josh Coalson
    once you get an estimate of the target sample for a
    given time, the AC3 decoder make take some time to
    sync the stream again.
    Because of the one-to-one frame correlation I mentioned above, this shouldn't be a problem as long as each chunk is a multiple of 6144 bytes (for converted AC3 files). The sync information is at the start of each frame, so the decoder shouldn't have to fall back to re-sync'ing if whole frames are always used.

    Andy: an alternative which you may not have considered is to rip separate AC3 files, encoding each one separately, then join the WAVs back together (just a matter of writing a new header containing the combined payload lengths and concatenating the payloads themselves). Generation of the CUE sheet would then be starting from a known set of WAV sizes... this might be useful if the source AC3 files have variable frame sizes and you don't just have frame numbers to go on. (Disclaimer: I haven't tried the conversion with such AC3 files although I don't see why it wouldn't work. As usual, I'll be interested to hear about any results and can patch the utility if it doesn't just work.)

  9. #29
    Senior Member
    Join Date
    May 2005
    Location
    UK
    Posts
    707
    Thanks for those thoughts.

    The calculation I've done thus far appears to work well enough for me ('track' breaks *appear* to be in the correct place, they're certainly 'close enough') and I haven't had any instance where changing to a new track causes some odd noise or whatever to come out of my decoder.

    Is anyone interested in the two files I've generated? The first is just a shell script to carry out all the steps necessary to rip to a single tagged / CUEsheeted FLAC. The second is a bit of Perl that reads in the _INFO.txt file generated by SmartRipper to create a CUE sheet and empty set of tags for the file.

    One thing I have noticed is that there seems to often be an 'extra' chapter on the DVD (at the end). I haven't checked to see if this is zero length (and hence could be deselected at the ripping stage) but DVD players seem to ignore this extra chapter (or skip over it very quickly).

    Andy

  10. #30
    Senior Member
    Join Date
    Jun 2005
    Posts
    285
    Quote Originally Posted by eldebil
    My test was the following:
    software :
    ---16 mn of "Faithless - Live at Alexendra Palace" (DTS half rate )
    ...
    A quick follow-up: I borrowed that DVD and have tried this myself, and have similar success -- in other words, none of the jerkiness I experienced with my full-bitrate DTS file.

    (Not that I doubted your results! I wanted to eliminate the possibility that differences in our systems could explain it, which seemed unlikely but worth making a basic test against.)

    To answer my own earlier question, the bitrate of the final FLAC file is 1494 kbps. Recall that the FLAC encapsulating a full-bitrate DTS stream was 1536kbps, so there's not a lot in it; if optimisation of the firmware's FLAC decoding routines is possible, perhaps there's not a lot of extra performance that we need squeezed out of it... :-)

Posting Permissions

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