|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
In Reply to: Re: No, You're Spouting Nonsense. Read... posted by NotMe on January 27, 2003 at 19:18:51:
The 1.5 kbs is not always used on a 'regular' DTS encoded disc.Also 'normal' DTS doesn't have a frequency range up to 24kHz. One of te losses in the lossy coding scheme is that hf above 20kHz is filtered to save bitspace. I doubt that the DTS9624 encoding extends the frequency range to a 'useless' 48kHz frequency range.
You forget that there are twice as many samples available in the 20-24kHz range with DTS9624.
Like John said win some loose some but in general DTS9624 is just slightly better.
Follow Ups:
> The 1.5 kbs is not always used on a 'regular' DTS encoded disc. <Half-rate DTS is known as just that, half-rate, so "regular" DTS is 1.5Mb/s. That is what my reference intended. Sorry for any confusion caused.
> Also 'normal' DTS doesn't have a frequency range up to 24kHz. One of te losses in the lossy coding scheme is that hf above 20kHz is filtered to save bitspace. <
No. From DTS' own literature (this particular example from http://www.dtsonline.com/dtsposition.pdf): "For 48 kHz sampling, DTS has response to 24 kHz at 1.5 Mbit/s and response to 19 kHz at 754 kbit/s."
> You forget that there are twice as many samples available in the 20-24kHz range with DTS9624. <
Wrong again. There aren't. The frequency range up to 24kHz is delivered by the core data, to remain backward compatible it has to be sampled at 48kHz. In a DTS 96/24 decoder, the 48kHz data is upsampled, so the actual content has no more samples. From the document previously referenced:
"The input digital audio signal with a sampling frequency up to 96 kHz and a word length up to 24 bits is processed in the core branch and extension branch. In the core branch input audio is low-pass filtered to reduce its bandwidth to below 24 kHz, and then decimated by a factor of two, resulting in a 48 kHz sampled audio signal. The purpose of this LPF decimation is to remove signal components that cannot be represented by the core algorithm."
> I doubt that the DTS9624 encoding extends the frequency range to a 'useless' 48kHz frequency range. <
Nope (I thought you were the tech guy around here?). The same AES document contains two graphs, the first shows uncompressed 96kHz PCM with a frequency response extending to 48kHz. The second shows the behaviour of the two DTS encoder halves, the core data, which rolls of steeply just before 24kHz and the residual component which mirrors the response of the uncompressed PCM right out to 48kHz.
As I said, try to get hold of some DTS technical documents, the 96/24 example in particular, prior to jumping the gun about the system's operation.
"The input digital audio signal with a sampling frequency up to 96 kHz and a word length up to 24 bits is processed in the core branch and extension branch. In the core branch input audio is low-pass filtered to reduce its bandwidth to below 24 kHz, and then decimated by a factor of two, resulting in a 48 kHz sampled audio signal. The purpose of this LPF decimation is to remove signal components that cannot be represented by the core algorithm."This doesn't say anything about upsampling the core data. It's just explaining how the core data is derived so it will be compatible.
As I understood it the missing samples are reconstructed by information contained in the extension data.
> This doesn't say anything about upsampling the core data. <Not this particular passage, but it demonstrates that the data is indeed separated into two halves, with the core data carrying everything up to 24kHz. The extension data, specified as "above 24kHz" carries the higher frequencies. There's nothing in the document about the extension data carrying frequencies below 24kHz sampled at a higher rate.
And just to revisit your assumption that a lossy CODEC wouldn't bother reproducing 48kHz signals, I've just spotted the following paragraph on a page fold:
"The graph in Figure 8 illustrates the capability of coding system to cover the entire bandwidth from 0-48kHz at a combined bit rate of 1536 kbps. As before 1152kbps is allocated to the core stream and 384kbps is allocated to the extension stream."
I don't know about you, but I think that's utterly pointless. Dedicating valuable data to inaudible content in a lossy coder makes no sense at all, unless one considers the marketing potential of the term "96/24" amongst those who don't appreciate how the technology works.
And, something we've not re-visited is the quality issue. I still maintain DTS 96/24 will and does sound worse than regular DTS because of the reduced data dedicated to the audible content, but whether that is a correct assumption or not, I know that anyone listening to a DTS 96/24 track on non-DTS 96/24 hardware will suffer, they're only getting 1,152kb/s.
Bits are dynamically allocated to signal content. If little signal content is availaible beyond 20kHz little bit space is used and the remaining bits get allocated to signals having a higher 'priority'.
The encoder selects different algorithms by analyzing the signals content.
The extension stream is additional data the term extension doesn't imply that it's used for the upper frequency range only.
> Bits are dynamically allocated to signal content. If little signal content is availaible beyond 20kHz little bit space is used and the remaining bits get allocated to signals having a higher 'priority'. <Thank you for agreeing with my point - a lossy coder with 48kHz response is pointless - being able to assign bits as required only underlines that point.
> The extension stream is additional data the term extension doesn't imply that it's used for the upper frequency range only. <
No - the DTS 96/24 is split in half as I explained at least once already.
Oh, and if you're still in doubt about upsampling:
"To decode a core+extension bit-stream, Figure 1 B), the unpacker first separates the stream into the core and extension data. The core decoder decodes the core data and produces the core LPCM audio that is next up-sampled to 96kHz using the 48-to-96kHz interpolator. The core decoding and interpolation are both performed in the “Reconstruct Core Audio Components” block."
What part of this do you not understand? Sheesh...
This post is made possible by the generous support of people like you and our sponsors: