True 32 bits of SPDIF interface (new IC specification) ??

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
The figure on page 14 of the CT-7301C datasheet looks like a bug. Or maybe it's just cryptic. ;) What it labels a frame is a pair of time slots with incorrect subframing. The 24 bit case in the figure is seems incorrect as it omits the aux channel and the 32 bit case is either invalid or a proprietary extension.

What seems more plausible is the extend mode uses the aux channel to ship 28 bit rather than 24 bit samples. This would help a bit (well, four bits) in systems with poor gain structure. With decent gain structure it's functionally irrelevant.
 
In any case it is pretty academic, as there aren't any 32 bit recordings.
Heh, in many recording situations it's nontrivial to get 70dB acoustic SnR, which is all of 6.13 bits. Some allowance for recording dynamic range, the ear's level tracking behavior, and ability to hear structured artifacts 20 dB or so below the noise floor yields the 16 bit standard. Digital volume at the source and common gain structure problems make 24 bit handy but I've never encountered a push to DAC case where more than 24 bit over SPDIF added value.

Where 32 and 64 bit are valuable is handling numerically stiff (low frequency) IIR filters as it's normal to need 16 signal path guard bits in deep bass and substantially more than that internal to the filter. There are cases where a SPDIF link ends up in the middle of a filter bank but they're rather obscure. People will buy 32 bits anyway because more must be better, though. So it's technically academic but useful in marketing.

page 2, table ????
If you want to get anywhere with this I'd suggest asking Comtrue. There's insufficient information in the datasheet on their website for meaningful conclusions to be reached. You may find it useful to look at how ADAT Lightpipe works and do workback math on the Toshiba and Everlight parts called out in the eval board---that should help you understand the 384k limit on the SPDIF side.

Alternatively, if this product announcement indicates you're associated with Comtrue it would be appropriate to disclose the relationship and work to improve the datasheet so that it's clear as to the protocol used and interface requirements and reaches characterization parity with competing parts with other vendors. If the intention's to generate buzz about the part the proper forum to post in is the Vendors' Baazar.
 
True 32 bits SPDIF interface

Well, you define a missing/additonal format what ASES3 (protocol) do not have. Your format is block aligned to 40 bits :rolleyes:

The current situation is, that ALL ADC/DAC do not fully provide a real 24 bit performance also within the full freq. range, likely 22..23 bits or even less (marketing format).

I would rather see a more open transportation format as supporting float format support too. :D

my 2 cents

Hp
 
I assume you are joking.

Not really, ASIO & WASAPI supports already float formats from application to the HW and I do not understand why the transport layer may not support this.

Who knows, using float numbers might solve a lot of ground loop related hum problems! :rolleyes:

IMHO, this one is for joking, or please explain why a protocol layer alters hum :D

Hp
 
Not really, ASIO & WASAPI supports already float formats from application to the HW and I do not understand why the transport layer may not support this.

But why would you ever need it? 32 bit float doesn't have any more resolution than 24 bit integer, and the only benefit of the floating format is in case you have non-normalized data that is grossly out of range.

Float is useful as an intermediate calculation format, but not as a format for transmission and storage.
 
new specification

===============================================

CT-7301C Audio SRC Bridge : True 32 bits of SPDIF

===============================================

Key Features:

SPDIF support up to 384 KHz / 32 bits mode.


this feature means :

spdif receiver is auto detect 24/32 bits, 32kHz ~384kHz

spdif transmitter is programming 24/32 bits, 32kHz ~384kHz

spdif RCA can support 32kHz ~ 384kHz or more(system issue)

spdif optical can support 32kHz ~ 192kHz or more(system issue)

spdif can transport pcm (up to 32 bits), or non-pcm (up to 32 bits, too)

or DoP (DSD on PCM)
 
sampling rate converter

===============================================

CT-7301C Audio SRC Bridge : True 32 bits of SPDIF

===============================================

Key Features:

32 bits SRC

this feature means :

. input Fs = 32kHz ~ 768Khz (auto detection)

. output Fs = 32kHz ~ 768Khz (easy to set h/w or s/w)

. 32-bit DSP core

. SNR up to 32 bits (192dB)
 
But why would you ever need it? 32 bit float doesn't have any more resolution than 24 bit integer, and the only benefit of the floating format is in case you have non-normalized data that is grossly out of range.

Float is useful as an intermediate calculation format, but not as a format for transmission and storage.

Julf: I am not an electronic engineer or a computer programmer. I am a recording/sound engineer though.

Some DAW have a 32 bit audio engine and 32bit floating point DSP/plugins (ie. Soundbooth & Audition ). I read several years ago it was a good idea to save your recordings as 32bit or use 32bit copies of your 24bit originals to minimize errors and maximize sound quality. Protools use to have a 48bit Mixer (DAE-Digidesign Audio Engine). I don't recall if the plugins were 32 bit or 48 bit (RTAS & Audiosuite). Protools 11 is using a 64 bit engine now so the plugins and dsp are 64bit AAX format. PT11 offers to save your 24bit recording as 32bit float as a default. I would think it comes back to not having your DAW have to sample rate convert on the fly as it read audio files from your hard drive, especially if you are doing a high track count (only PT-HD loads complete audio files into ram for your mixing session) .
It is not about headroom and audio noise floors. It is about sample and DSP accuracy; and reducing the work load on your Audio Engine Many plugins sound/work much better at higher resolution, even though the final product is going to be stone age 16bit/44.1k format. The source effects the final product.
Cirrus makes 32 bit AD chips now.
Someone is selling 32 bit AD/DA hardware.
Antelope is selling AD/DA with "64bit clocks" in their converters- whatever that means, not sure if the audio is 32bit or 24bit.
Sample rate conversion works best when working in even order magnitudes of the source and destination format. ie: 16/32/64bit 44.1k/88.2k/176.4k for audio. Video/Post professionals like 24bit 48k/96k/192k sampling.
~erick~
 
Last edited:
IEC60958 doesn't permit 32 bit audio transfer.

Also, there's no difference in quality going from, say, 44.1->88.2 versus 44.1->96K. Sure, the process is a bit more complicated, but ultimately you're just pulling samples out of a polyphase FIR running over the input samples.
 
I was not addressing your post about IEC. I was addressing Julf statement it does not matter. I have never up-sampled my source audio files, and I have mixed a lot of 16/44.1k source files for college. But I do Record in 24bit/88.2, the sound quality is incredible but I will tell you after a week of mixing and then a bounce to 16bit/44.1k the sound quality is very unnerving, like slap in the face ! (why did I even bother spending 20 hours mixing a song) There is a very real difference in 24bit 88.2k audio. A typical consumer will never get the chance to hear studio audio files. ...Any good engineer will tell you to sample in a multiple of your finished product. Less errors . . .
 
Last edited:
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.