FLAC 44.1 kHz/16 bit stereo (CD) converted to 44.1 kHz/*24* bit PCM for optical output?

[Al Lee]

When playing FLAC files from my Minimserver media server, which were ripped from my CDs at 44.1 kHz/16 bits, the Wiim pro outputs a 44.1 kHz/ *24* bit PCM stream over optical SPDIF/toslink. I am connecting the Wiim Pro to my Minimserver via the Home Music Server tab in the Wiim Home app on an iPhone, then selecting albums/tracks to play. The optical output goes into a Linn Klimax DSM, and that is what is reporting the higher bit rate. I have the optical output set in the Wiim Pro for a maximum of 192 kHz/24 bits.

Note: when I play FLAC files directly on the Linn DSM from the Minimserver, the bit rate/depth is correctly reported as a 44.1 kHz/16 bit FLAC source.

My guess is that, in decompressing the (lossless) FLAC files, Wiim just puts both 16 bit and 24 bit sources into 24 bits for convenience, setting the least significant 8 bits to zero when the source is 16 bits.

Is this true? Or is something weird going on as Wiim decompresses my FLAC files?

 

[d6jg]

You said output was Optical so why is the WiiM doing any decompression at all? It should deliver the untouched Flacs to your Linn where the decompression and conversion to analogue takes place. Shouldn’t it? I’m confused

 

[onlyoneme]

You said output was Optical so why is the WiiM doing any decompression at all? It should deliver the untouched Flacs to your Linn where the decompression and conversion to analogue takes place. Shouldn’t it? I’m confused

WiiM doesn't send files over digital output. It sends raw pcm stream for dac, so flac content must be decompressed first.

 

[Al Lee]

You said output was Optical so why is the WiiM doing any decompression at all? It should deliver the untouched Flacs to your Linn where the decompression and conversion to analogue takes place. Shouldn’t it? I’m confused

onlyoneme is right: S/PDIF is a very limited protocol, transmitting only uncompressed PCM stereo or compressed 5.1 multichannel. The losslessly compressed FLAC file specification is not supported.

Reading the description of S/PDIF on Wikipedia, I think I understand why the bit depth of my FLAC files is upscaled to 24 bits. The only options for uncompressed stereo bit depths in the S/PDIF protocol are 20 bits or 24 bits per channel. Hence Wiim had to pick one or the other, then pad with zeros the extra bits. Might as well use 24 bits, since that will handle the higher bit depth files as well.

S/PDIF - Wikipedia

en.wikipedia.org

 

[onlyoneme]

onlyoneme is right: S/PDIF is a very limited protocol, transmitting only uncompressed PCM stereo or compressed 5.1 multichannel. The losslessly compressed FLAC file specification is not supported.

Reading the description of S/PDIF on Wikipedia, I think I understand why the bit depth of my FLAC files is upscaled to 24 bits. The only options for uncompressed stereo bit depths in the S/PDIF protocol are 20 bits or 24 bits per channel. Hence Wiim had to pick one or the other, then pad with zeros the extra bits. Might as well use 24 bits, since that will handle the higher bit depth files as well.

S/PDIF - Wikipedia

en.wikipedia.org

Not exactly AFAIK. Audio data block in spdif is indeed 20 + 4 bits but there is also a bits combination in the channel status block to declare sample length between 16 to 24 bits. Maybe WiiM does not set it correctly.

 

[dudu]

When playing FLAC files from my Minimserver media server, which were ripped from my CDs at 44.1 kHz/16 bits, the Wiim pro outputs a 44.1 kHz/ *24* bit PCM stream over optical SPDIF/toslink. I am connecting the Wiim Pro to my Minimserver via the Home Music Server tab in the Wiim Home app on an iPhone, then selecting albums/tracks to play. The optical output goes into a Linn Klimax DSM, and that is what is reporting the higher bit rate. I have the optical output set in the Wiim Pro for a maximum of 192 kHz/24 bits.

Note: when I play FLAC files directly on the Linn DSM from the Minimserver, the bit rate/depth is correctly reported as a 44.1 kHz/16 bit FLAC source.

My guess is that, in decompressing the (lossless) FLAC files, Wiim just puts both 16 bit and 24 bit sources into 24 bits for convenience, setting the least significant 8 bits to zero when the source is 16 bits.

Is this true? Or is something weird going on as Wiim decompresses my FLAC files?

Nothing is wrong. It has to be this way as it's S/PDIF. Even when i change the WiiM to 16 bit my Selekt DSM displays 24 bit.
@onlyoneme: Any links regarding channel status block? My Google results don't indicate something like sample length. Maybe @WiiM Support can put some light on this.

 

[onlyoneme]

Nothing is wrong. It has to be this way as it's S/PDIF. Even when i change the WiiM to 16 bit my Selekt DSM displays 24 bit.
@onlyoneme: Any links regarding channel status block? My Google results don't indicate something like sample length. Maybe @WiiM Support can put some light on this.

Even on wiki you can see this (spdif topic)

4 0 Word length 20 bits Word length 24 bits
4 1-3 Sample length (0=undefined, 1-4=word length minus 1-4 bits, 5=full word length)

but more details here, for example

https://tech.ebu.ch/docs/tech/tech3250.pdf

BTW RME ADI-2 shows correct bit depth, but it analyzes incoming stream for "empty" bits.

 

[dudu]

Even on wiki you can see this (spdif topic)

4 0 Word length 20 bits Word length 24 bits
4 1-3 Sample length (0=undefined, 1-4=word length minus 1-4 bits, 5=full word length)

but more details here, for example

https://tech.ebu.ch/docs/tech/tech3250.pdf

BTW RME ADI-2 shows correct bit depth, but it analyzes incoming stream for "empty" bits.

@onlyoneme: You're the man. I was stuck with the german Wikipedia. Shame on me ...

 

[onlyoneme]

@onlyoneme: You're the man. I was stuck with the german Wikipedia. Shame on me ...

I've raised a ticket regarding missing sample rate data in the channel status block and it has been fixed on the Mini. I can only guess that maybe sample length data is still missing.

 

[Al Lee]

I've raised a ticket regarding missing sample rate data in the channel status block and it has been fixed on the Mini. I can only guess that maybe sample length data is still missing.

The spec you give is for AES/EBU, the European standard that is more explicit than the Sony/Phillips Digital Interface (S/PDIF) specification.
A few pages I have found, like the the English S/PDIF Wikipedia page, point out that the extra 4 bits used to get 24 bit words in the S/PDIF protocol are for undefined extra status, but, since they are undefined and adjacent to the 20 bits of signal, manufacturers have just taken to using them optionally for audio signal.

The way S/PDIF works (unlike AES), almost all critical information, like bit rate, are determined just by looking at the bit stream - if bits are coming in quickly, then it is a high bit rate stream - it makes sense that how receivers determine the bit depth is just by looking at what bits are consistently zero.

The only status bits in S/PDIF that seems to have any meaning are the first two status bits of the first word of every frame: the first one says whether it is S/PDIF (consumer AES) or Professional AES, and the second says whether the content is PCM encoded stereo audio, or compressed surround sound or something else.

Note: even the English Wikipedia page gets confused after a while, linking to AES documentation to explain S/PDIF.

Wayback Machine

Even if the Wiim Pro implements AES consumer correctly with all status bits, including word length (bit depth) and bit rate, it is not guaranteed *receivers* implementing S/PDIF will look at those bits to determine bit rate and bit depth.

This document seems to be close to authoritative on S/PDIF:

https://www.st.com/resource/en/application_note/an5073-receiving-spdif-audio-stream-with-the-stm32f4f7h7-series-stmicroelectronics.pdf

"S/PDIF is based on the AES3 interconnect standard. S/PDIF and AES3 are compatible at the protocol level but their electrical characteristics differ, for exampe in terms of voltage levels and impedance. S/PDIF can carry two channels of uncompressed PCM audio, or compressed 5.1/7.1 surround sound (such as DTS audio codec data). However, due to limited bandwidth, it does not support uncompressed audio formats (other than 2-channel LPCM) such as Dolby True HD and DTS master.

S/PDIF doesn’t specify any default data transmission rate. The device has to extract the clock from the input signal. This is achieved by use of bi-phase mark code that includes one or two transitions for each bit. The transmission rates typically used are 44.1 kHz for stereo CD audio, and 48 kHz for digital audio tape (DAT). The standards also support simple stereo streams up to a high sample rate (192 kHz)."

By the way, this process, where manufacturers put out an underspecified spec to fill a need, then an international standards body attempts to clean it up, is extremely common for computer communication protocols and even computer programming languages. See the history of Fortran.

 

[onlyoneme]

The spec you give is for AES/EBU, the European standard that is more explicit than the Sony/Phillips Digital Interface (S/PDIF) specification.
A few pages I have found, like the the English S/PDIF Wikipedia page, point out that the extra 4 bits used to get 24 bit words in the S/PDIF protocol are for undefined extra status, but, since they are undefined and adjacent to the 20 bits of signal, manufacturers have just taken to using them optionally for audio signal.

The way S/PDIF works (unlike AES), almost all critical information, like bit rate, are determined just by looking at the bit stream - if bits are coming in quickly, then it is a high bit rate stream - it makes sense that how receivers determine the bit depth is just by looking at what bits are consistently zero.

The only status bits in S/PDIF that seems to have any meaning are the first two status bits of the first word of every frame: the first one says whether it is S/PDIF (consumer AES) or Professional AES, and the second says whether the content is PCM encoded stereo audio, or compressed surround sound or something else.

Note: even the English Wikipedia page gets confused after a while, linking to AES documentation to explain S/PDIF.

Wayback Machine

Even if the Wiim Pro implements AES consumer correctly with all status bits, including word length (bit depth) and bit rate, it is not guaranteed *receivers* implementing S/PDIF will look at those bits to determine bit rate and bit depth.

This document seems to be close to authoritative on S/PDIF:

https://www.st.com/resource/en/application_note/an5073-receiving-spdif-audio-stream-with-the-stm32f4f7h7-series-stmicroelectronics.pdf

"S/PDIF is based on the AES3 interconnect standard. S/PDIF and AES3 are compatible at the protocol level but their electrical characteristics differ, for exampe in terms of voltage levels and impedance. S/PDIF can carry two channels of uncompressed PCM audio, or compressed 5.1/7.1 surround sound (such as DTS audio codec data). However, due to limited bandwidth, it does not support uncompressed audio formats (other than 2-channel LPCM) such as Dolby True HD and DTS master.

S/PDIF doesn’t specify any default data transmission rate. The device has to extract the clock from the input signal. This is achieved by use of bi-phase mark code that includes one or two transitions for each bit. The transmission rates typically used are 44.1 kHz for stereo CD audio, and 48 kHz for digital audio tape (DAT). The standards also support simple stereo streams up to a high sample rate (192 kHz)."

By the way, this process, where manufacturers put out an underspecified spec to fill a need, then an international standards body attempts to clean it up, is extremely common for computer communication protocols and even computer programming languages. See the history of Fortran.

I've pointed to AES spec simply because it's the same as spdif one regarding mentioned part of the channel status data. No one can predict if the receiver device will use it but being compliant with the spec gives higher chance of proper work.

If you want details just look for IEC 60958-3 spec. Unfortunately it is not for free usually.

 

[onlyoneme]

As for the consumer standard which is spdif:

 

[Al Lee]

I've pointed to AES spec simply because it's the same as spdif one regarding mentioned part of the channel status data. No one can predict if the receiver device will use it but being compliant with the spec gives higher chance of proper work.

If you want details just look for IEC 60958-3 spec. Unfortunately it is not for free usually.

The first IEC spec came in 1999, *after* the AEC/EBU spec, which was first published in 1985. Both came after Sony and Phillips put out their specification in 1980, and Toshiba specified the Toslink optical link in 1983.

Note the "Note 2" in the IEC spec you quote: originally in 1999 all these bits indicating word length were zero, so word length information was *not* passed from the sender to receiver as part of even the IEC (last) spec.

Hence a sender implementation that conforms to the original S/PDIF spec, or original AEC/EBU spec, or original IEC spec, would not set these bits, and an implementation of a receiver that wants to be maximally backward compatible with older equipment would not expect these word length bits to be set.

Backward compatibility is a bit**, as are evolving specifications over 30+ years.

SPDIF vs Optical (Differences & Reasons To Use Each)

Considering that SPDIF and optical are digital connections, some people might think they're interchangeable or that SPDIF is a type of optical connection.

producerhive.com

 

[onlyoneme]

The first IEC spec came in 1999, *after* the AEC/EBU spec, which was first published in 1985. Both came after Sony and Phillips put out their specification in 1980, and Toshiba specified the Toslink optical link in 1983.

Note the "Note 2" in the IEC spec you quote: originally in 1999 all these bits indicating word length were zero, so word length information was *not* passed from the sender to receiver as part of even the IEC (last) spec.

Hence a sender implementation that conforms to the original S/PDIF spec, or original AEC/EBU spec, or original IEC spec, would not set these bits, and an implementation of a receiver that wants to be maximally backward compatible with older equipment would not expect these word length bits to be set.

Backward compatibility is a bit**, as are evolving specifications over 30+ years.

SPDIF vs Optical (Differences & Reasons To Use Each)

Considering that SPDIF and optical are digital connections, some people might think they're interchangeable or that SPDIF is a type of optical connection.

producerhive.com

Referring to the previous specs doesn't make sense as they are evolving which makes previous ones obsolete.

AES 2003 spec:

IEC 958 1989 probably:


If anyone wants to conform to a spdif specification, it must be the current one.

 

[Al Lee]

Referring to the previous specs doesn't make sense as they are evolving which makes previous ones obsolete.

AES 2003 spec:
View attachment 297
IEC 958 1989 probably:
View attachment 298

If anyone wants to conform to a spdif specification, it must be the current one.

In the consumer electronics space, there are *many* devices that were created before the current specs were written, and with which even modern equipment will want to be backward compatible.

Note S/PDIF was defined in 1980, and Toslink in 1983. I bought home audio equipment in the 1990s that conformed to the specs of that era (the first IEC spec was only in 1999). I would expect Wiim and other modern devices to be able to talk to them.

It is actually a pretty recent phenomena that an audio device like Wiim, a CD player, a receiver, or a TV, is capable of software upgrades over the Internet. My HDTV bought in 2007 and AV receiver bought in 2008 are *not* Internet upgradeable. It is basically impossible to update these devices to match later specs.

Protocols that are backward compatible are best. Devices that are capable of successfully interacting with devices that implement any version of the spec are even better.

By the way, those definitions of bit patterns mapping to sample frequencies in the spec you quote are different from the ones I have seen, e.g., in this document about the AEC spec. If the definition of the bits vary across specs, then that is a strong reason for a S/PDIF receiver to measure the actual delivered bit rate and use that to determine the sample frequency, since that works the same across all specs.

 

[onlyoneme]

In the consumer electronics space, there are *many* devices that were created before the current specs were written, and with which even modern equipment will want to be backward compatible.

Note S/PDIF was defined in 1980, and Toslink in 1983. I bought home audio equipment in the 1990s that conformed to the specs of that era (the first IEC spec was only in 1999). I would expect Wiim and other modern devices to be able to talk to them.

It is actually a pretty recent phenomena that an audio device like Wiim, a CD player, a receiver, or a TV, is capable of software upgrades over the Internet. My HDTV bought in 2007 and AV receiver bought in 2008 are *not* Internet upgradeable. It is basically impossible to update these devices to match later specs.

Protocols that are backward compatible are best. Devices that are capable of successfully interacting with devices that implement any version of the spec are even better.

By the way, those definitions of bit patterns mapping to sample frequencies in the spec you quote are different from the ones I have seen, e.g., in this document about the AEC spec. If the definition of the bits vary across specs, then that is a strong reason for a S/PDIF receiver to measure the actual delivered bit rate and use that to determine the sample frequency, since that works the same across all specs.
View attachment 301

IEC-958 is 1989, not 1999:

IEC-958 | Digital Audio Interface | Document Center, Inc.

IEC-958 Digital Audio Interface

www.document-center.com

We are talking about the device released in 2021, not a one released before the specifications have been written.

My specs were correct. You are misaligning specs and spec parts, the one you've attached is a simplified version of consumer spec:


The spec uses 0-23 bytes convention, not 1-24.



TBH I've no idea what you are arguing with. Spdif specs are backwards compatible and channel status metadata is mostly not mandatory. But it doesn't mean it is not used by receiver devices.

 

[Al Lee]

IEC-958 is 1989, not 1999:

IEC-958 | Digital Audio Interface | Document Center, Inc.

IEC-958 Digital Audio Interface

www.document-center.com

We are talking about the device released in 2021, not a one released before the specifications have been written.

My specs were correct. You are misaligning specs and spec parts, the one you've attached is a simplified version of consumer spec:


The spec uses 0-23 bytes convention, not 1-24.



TBH I've no idea what you are arguing with. Spdif specs are backwards compatible and channel status metadata is mostly not mandatory. But it doesn't mean it is not used by receiver devices.

I was looking at the IEC 60958-3 spec, the first version of which is 1999. I stand corrected there was an earlier 1989 spec from IEC, IEC-958. I didn't realize you were posting information about the pro spec with the sample frequency bits part, hence my confusion about the seemingly incompatible bit definitions (no 32 kHz) with the consumer part.

I agree it is likely best for Wiim to attempt to conform to the latest version of the S/PDIF spec, the IEC consumer spec IEC 60958-3:2021.

I would not be surprised if a lot of S/PDIF receivers don't bother with reading the status block to get word length and sample frequency, since, at least for PCM stereo, these can be determined by just looking at the audio data stream, and taking that approach works will all older versions of specs for S/PDIF transmitters.

I have experience with trying to get developers to follow the full spec (in my case XML SOAP), when they didn't really feel it was necessary for the application they were writing. I have yet to meet a software developer who likes reading protocol specs.