chrisgeary Wrote: 
> could you confirm whether the spdifconvert utility will correctly handle
> 24bit DTS? I've tried ripping the Monster soundtrack by BT and some of
> the channel levels sound out to me. Also, the first track had a bit of,
> what I can only describe as, jitter noise. 
> 
> I ended up with 16 bit 48khz wav files - and whilst I can't find
> anything on google to help me decipher whether they should be 16bit or
> 24bit, I had a feeling that it was 24 bit.Interesting question.  My main 
> answer: I don't know for sure.

I've just been looking through some of the notes I made when writing
the utility, and I see that I read and interpreted the bits at the head
of a DTS frame when testing (from "test.dts" unfortunately, so I don't
know what the source of the file was; I assume it was one of the 5.1
music tracks I've successfully played through the SB2, but that's not
certain).  That file was 24-bit 48kHz, so assuming I played it back
successfully post-conversion, the utility supports those files. 
(Supports them intrinsically, that is, without any special handling.)

Here's what I _think_: the fact that the WAV files are 16-bit 48kHz
should not be an issue.  When converted to WAV, it's one format
supported by the SB2/3, so it's a handy way for us to package things. 
(Different sample sizes and rates for FLAC might be supported though,
so if it turns out to be useful, we can consider encoding to a
different WAV format.)

The S/PDIF-ready DTS stream packed inside the WAV is not itself
necessarily stored in 24-bit quantities: DTS is lossily compressed, so
24-bit samples for 6 channels sampled at 48kHz would give us a bitrate
of about 6.75 mbit/s (16-bit 48kHz stereo WAV ~= 1.5mbit/s; multiply by
three for the extra channels and add half for the increased sample
size).  Rather, I think that the DTS data is stored in a special format
which doesn't rely on being transmitted in discrete 16-bit chunks.  It's
a bitstream rather than a sequence of 16-bit quantities.  That bitstream
may not be 24-bit, but will be decoded to 6 channels of 24-bit data by
the receiver.

I could be wrong, of course; as I've said before, I'm no expert in
surround-sound encoding or the transmission thereof.  Having said that,
I'd be surprised if the channel levels sounding odd could be explained
by the 16- versus 24-bit situation here.  My experience with DTS files
has been that if something's wrong, you hear nothing sensible; there
don't seem to be half-measures whereby some parts would sound okay and
some wouldn't.  Everything has to be perfect for the receiver to be
able to spot a DTS stream and begin to decode it, as far as I know.

Jitter noise: I gather that for standard stereo PCM this is an effect
caused by the timing of the transmitted bytes not being perfectly
regular.  Is that right?  So some samples would be received (and
played) fractionally earlier or later than others.  I don't know how
that sounds; I don't think my ears would be able to detect it.  I don't
know if DTS data suffers from jitter problems; I'd always thought that
the bitstream would need to be slightly buffered anyway, and that the
receiver would decode and play back based on its own clock.  (But
again, I'm not an expert -- my q6 Oggs sound indistinguishable from
WAVs to me, and the imperfections detectable to some people are,
fortunately, inaudible to my ears.)

Perhaps you could try something: queue up the first track on your
SqueezeBox, and queue up the DVD also.  Try switching between the two
(blindfolded, with somebody else doing the switching, if possible) to
see if the incorrect sound levels are as mastered, or uniquely a
problem with the converted track.

If there's definitely a difference, reply back to this thread and we'll
see what else we can think of.


-- 
smst
------------------------------------------------------------------------
smst's Profile: http://forums.slimdevices.com/member.php?userid=752
View this thread: http://forums.slimdevices.com/showthread.php?t=19260

_______________________________________________
ripping mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/ripping

Reply via email to