Converting WAV to FLAC which FLAC Level is sufficient

[Eirikur]

For the purposes of this discussion, USB 1.1 and USB 2.0 work exactly the same way. The only relevant difference is the higher data rate of USB 2.0. The latency of USB 2.0 can be lower due the packet rate being 8x higher. The transaction types and their ability to resend corrupted packets are exactly the same.

I agree: both the USB Audio Class (1) protocol and the USB Audio Class 2.0 protocol prescribe isochronous data transfers for the audio data, not "bulk". This implies that any kind of retry mechanism must be custom built for either protocol. Given the limited bandwidth of USB1.1 retries may be physically impossible, take for example 96kHz/24bit stereo which eats up half the bandwidth in raw bits.
With the advent of very high frequency audio formats, bandwidth is still limiting even on USB2.0 - take for example 384kHz/32bits stereo.

Any generic implementation of the protocol (like the default Windows driver) will not implement any retry on the isochronous transfers, since neither standard caters for this. The only possibility is a custom driver provided by the vendor, and the protocol must also be implemented in the USB firmware of the device of course.

PS: it wasn't easy to find the USB Audio Class 2.0 protocol document, I couldn't locate it on the usb.org website. (thanks @mansr)

 

[wynpalmer]

I agree: both the USB Audio Class (1) protocol and the USB Audio Class 2.0 protocol prescribe isochronous data transfers for the audio data, not "bulk". This implies that any kind of retry mechanism must be custom built for either protocol. Given the limited bandwidth of USB1.1 retries may be physically impossible, take for example 96kHz/24bit stereo which eats up half the bandwidth in raw bits.
With the advent of very high frequency audio formats, bandwidth is still limiting even on USB2.0 - take for example 384kHz/32bits stereo.

Any generic implementation of the protocol (like the default Windows driver) will not implement any retry on the isochronous transfers, since neither standard caters for this. The only possibility is a custom driver provided by the vendor, and the protocol must also be implemented in the USB firmware of the device of course.

PS: it wasn't easy to find the USB Audio Class 2.0 protocol document, I couldn't locate it on the usb.org website.

In actuality retries would be of limited utility. I have a USB link of c. 10m that includes a 5m active extender cable.
The only time that I have ever observed a CRC flagged error is when I have deliberately degraded the link by using a passive extender cable.
The DAC software includes a utility for the PC that provides this, and other, information about the USB/DAC performance.

 

[mansr]

PS: it wasn't easy to find the USB Audio Class 2.0 protocol document, I couldn't locate it on the usb.org website.

https://usb.org/sites/default/files/Audio2.0_final.zip

All versions: https://usb.org/documents?search=audio&type[]=55

 

[maty]

The DAC sample clock may be asynchronous, but I believe that the interface remains isochronous as that mode is what is used to guarantee throughput.
As was described before by mansr, modern USB DACs use isochronous mode with asynchronous sample clock management.
This means that there is no data resend.

In the case of ODAC, what interests me is knowing whether or not there is data resending. I have always believed so.
Otherwise, it could be the correct explanation for the differences I appreciate.

If the modern ones do not resend either, then when the DAC detects error, does it regenerate the data itself?

 

[maty]

Any generic implementation of the protocol (like the default Windows driver) will not implement any retry on the isochronous transfers, since neither standard caters for this. The only possibility is a custom driver provided by the vendor, and the protocol must also be implemented in the USB firmware of the device of course.

ODAC uses the generic Windows driver and do not have a custom device USB firmware.

From now on, when I investigate DAC, I will consider it.

 

[mansr]

In the case of ODAC, what interests me is knowing whether or not there is data resending. I have always believed so.

ODAC uses the generic Windows driver and do not have a custom device USB firmware.

If it works with generic drivers, that means it's a USB Audio Class device. As such, it uses isochronous mode without any retransmission of bad packets.

If the modern ones do not resend either, then when the DAC detects error, does it regenerate the data itself?

Error handling is not specified, so it will vary between DACs. Likely choices are to drop the bad data, replace it with zeros, or do some simple interpolation such as repeating the last good sample.

In practice, it doesn't matter how errors are handled since they are so rare. USB 2.0 does not specify a maximum error rate. USB 3.2 specifies an average error rate of no more than 1 in 10^12 bits. It is reasonable to assume that a typical USB 2.0 implementation is no worse. For 192 kHz 24-bit audio, that amounts to one error in 30 hours. For CD quality it is less than one error per week. Unless you live a sound-proofed bunker, your listening will be disturbed by other things far more often. You can stop worrying about this.

 

[maty]

Then I still do not have a convincing explanation

 

[Soniclife]

Then I still do not have a convincing explanation

You do, you imagined it.

Only when you have a controlled listening test where you prove its audible ears only do you need to look for an explanation.

 

[maty]

WiFi from PC (second system) to main system, DLNA. Files from excellent 24/192 FLAC vinyl rip. Conversion with foobar2000 1.4.2 and FLAC 0. libFLAC 1.3.2 20170101. SoX resampler. All files are DR15.

MP3 with LAME3.99r -m j -V 4 -q 3 -lowpass 20.5

03. is at 48 kHz and 04. at 44 kHz (standard)

JRiver MC 24.0.78. Control with the phone, with Gizmo app.

* FLAC 0. The winner is 01. S0X 24-96 A1 Aqualung.flac

* MP3 320 kbps: The winner is 03. MP3 320 A1 Aqualung.mp3 (48 kHz)


The best of all, 01. S0X 24-96 A1 Aqualung.flac

 

[maty]

If someone wants the files sent me an e-mail: https://nauscopio.wordpress.com/about/

By the way, I did not expect so much difference in sound in MP3, 48 kHz vs 44 kHz, it is very striking. I forgot to compare FLAC ? with WAV.

 

[solderdude]

I did not expect so much difference in sound in MP3, 48 kHz vs 44 kHz, it is very striking. I forgot to compare FLAC ? with WAV.

That is only because you have the bottle necks removed.
Usually when that happens the getter deposits turns white.

 

[danadam]

On one machine I have:

idVendor=262a, idProduct=1048
Product: ODAC-revB
Manufacturer: Yoyodyne Consulting

and lsusb says:

	Transfer Type            Isochronous
	Synch Type               Adaptive

For comparison, on another machine I have:

idVendor=21b4, idProduct=0081
Product: UDA-01 96KHz USB DAC
Manufacturer: Gmaxtech AudIo.

and lsusb says:

	Transfer Type            Isochronous
	Synch Type               Asynchronous

There's Fundamentals-of-USB-Audio(1.0).pdf and usb-audio-simplified.pdf that describe those synchronization modes.

 

[maty]

That is only because you have the bottle necks removed.
Usually when that happens the getter deposits turns white.

Does your comment contribute anything?

And the old BIG speakers (woofer: 27 cm aka 10.6 ") have the cones of paper -> sound less detailed than with my metallic coaxial speakers. Both fill the room.

 

[solderdude]

It contributes by adding some humor (or at least I hoped it would)

 

[maty]

I hope you understand my susceptibility, as others have used humor maliciously in the past. I am sorry.

 

[solderdude]

Well t.b.h. it was a bit at your expense... but intended as humor you may have appreciated as well.

 

[Blumlein 88]

That is only because you have the bottle necks removed.
Usually when that happens the getter deposits turns white.

Tube based humor. We need a GIF for that.

 

[graz_lag]

Then I still do not have a convincing explanation

In Tarragona you have the beautiful Sala del Sarcófago de Hipólito, what abt. doing listening comparison in here ?
Perhaps its acoustic would let you hear the very last bit you're afraid to lose ...

 

[maty]

Off topic

After Rome, the ancient Imperial Tarraco (Tarragona today) has the best Roman remains that are preserved in Europe. Many years ago (2004) I created a website about it. In HTML and manually edited code: http://maty.galeon.com/tarragona/

Unfortunately, the people of Tarragona are deeply unaware of the history of their city and have not been able to promote it until recently.

https://en.wikipedia.org/wiki/Tarraco

 

[Pluto]

If the modern [DACs] do not resend either, then when the DAC detects error, does it regenerate the data itself?

Please don't loose too much sleep over this. I have a DAC which detects the accuracy of incoming data using a specially constructed test signal. I attached the DAC to a low-powered computer via three repeating 5m USB extensions. No errors, not one bit. Nichts. Nowt. Zilch.

I doubt errors are an issue with the typical 1m link between computer and DAC unless you use a really kooky specialist audiofool USB cable that strays so far from the USB spec. as to achieve a remarkable sound.