#31
19th April 2010
19th April 2010
#31
Lives for gear

Quote:
Originally Posted by HLStudios
You seem to have very little experience and your equipment is lower than entry level from what I have read.

I dont know why you are trying so hard to be an expert when you are clearly not.

Take the time to do a little bit of reading. When you understand what should happen and under what circumstances you will be able to make it happen with out all the try anything and see what happens routine.

In what way are you trying to create music?
Why are you questioning this? IMO it is perfectly legitimate to try to understand things by experimenting with whatever you have at hand. In fact I believe it's the only way to understand things. It is clear that Muriel has done his homework and has had enough theoretical background to start learning by doing. I don't think Muriel is trying to show off as an expert, he's just asking perfectly valid and reasonable questions...Maybe tell us how to BECOME an expert if it's not by trying hardly...
You also should have noticed that we are dealing with deterministic test signals here, not music.
#32
19th April 2010
19th April 2010
#32
Lives for gear

Quote:
Originally Posted by Muriel Esteban
This is true, but I will still miss 16711680 different values, not just 254.

I exactly played values [ 0, 1, 2, 3, ..., 99, 100, 101, 102, ..., 16777215 ] (I write them here unsigned, but in fact they are encoded in signed 24 bits integers).
The recorded data shows [ 127, 128, 129, 130, ..., 226, 227, 227, 228, ..., 16777087 ]: 254 values (0-126 and 16777088-16777215) are missing, and 254 values are doubled (as in my example: 100 and 101 were recorded at 227).

If somewhere in the path (between the played file and the recorded file) there was a 16 bits truncation (even with bits repadded afterwards), it would have been impossible to get such consecutive numbers precisely. A 16 bits truncation means that anyway I will loose at least 16711680 values.
Well, this is very unusual.
What might have happened is that the 8 LSB were truncated, and then the signal was, maybe partially, shifted in the range.
In any case there is some dubious bit manipulation going on.

Quote:
I just looked a bit around this pre-emphasis option. I don't understand yet how it can alter the signal.

Do you know a bit more about it ?
I think it's a way to encode the higher frequencies with more bits.
There is a precisely specified high frequency boost before sending the data over SPDIF. The stream includes a bit that will inform the other side that emphasis is enabled. The receiver applies a corresponding high frequency cut to compensate.

But that's what i can remember.

Quote:
I would have thought the same, but when I see how such a recording is not obvious, I fear the worse I really hope that you are right.

Your EMU testing makes me think that I just jumped on the cheapest audio interface for AES recording, and it should be an exception.

Yeah, you should never have trusted the ASUS.
It is a game/toy card not designed for pro audio use.

I'm pretty sure the Emu 1212 will do just as well as the 1616m and it only costs around \$150.
Not sure what cheaper alternatives there are.
#33
19th April 2010
19th April 2010
#33
Gear Guru

Quote:
Originally Posted by monomer
That's realy strange as there definitely SHOULD be padding if you record a 16 or 20 bit stream at 24 bits.
Altho almost any gain change at the recording side would overwrite the padded bits.

Yes, it is mostly a driver issue.
But there are other issues as well.
I read somewhere that if the windows mixer is used somehow, it will automaticly truncate everything to 16 bits if there is a 16 bit stream comming in.
So even if the soundcard drivers would provide for 24 bits, windows will fall back to 16 bits if there is a 16 bit source present anywhere in the chain.
So there are more issues to consider when using WDM drivers.

That SHOULD have yielded 24 bit transfer.

Yes, i understand your problem now.
This is definitely a gain change.
And it will mask any padded bits because a gain change will redistribute the non-padded bits across all the available bits if the gain change is not a power of 2.

So it is still uclear if it's only a gain change or if there is more involved.
I think your info on WDM is not complete or up to date. And it apparently wasn't when this 2003 explainer was written: http://www.digitalaudio.com/fileadmi.../WDM_Audio.pdf

There was a bug in the K-mixer (aka, KMixer; apparently affecting those with Win ME and Win 2000) that did truncate to 16 bits. But that was a decade ago and patches have been around since not long after.

Additionally, kernel-streaming mode WDM drivers, which bypassed the KMixer, were considerably more capable and better performing. The KMixer ended with XP.
#34
19th April 2010
19th April 2010
#34
Lives for gear

Quote:
Originally Posted by Muriel Esteban
If it appears my problems with recording might come to clock issues or jitter...
It's nearly always that!
#35
19th April 2010
19th April 2010
#35
Lives for gear

Quote:
Originally Posted by theblue1
I think your info on WDM is not complete or up to date. And it apparently wasn't when this 2003 explainer was written: http://www.digitalaudio.com/fileadmi.../WDM_Audio.pdf

There was a bug in the K-mixer (aka, KMixer; apparently affecting those with Win ME and Win 2000) that did truncate to 16 bits. But that was a decade ago and patches have been around since not long after.

Additionally, kernel-streaming mode WDM drivers, which bypassed the KMixer, were considerably more capable and better performing. The KMixer ended with XP.
But the paragraph about the Kmixer bit depth conversion mentions 2 separate problems. The path fixes only the second of these.
Muriel Esteban
#36
27th April 2010
27th April 2010
#36
Gear interested

I have just tested the M-Audio Audiophile 192 sound card.
It is also a PCI sound card with S/PDIF input/output, support for Asio and WDM drivers. I got it around 119 €. It can record 24 bits PCM data at 8, 9.6, 11, 12, 16, 22, 24, 32, 44.1, 48, 88.2, 96, 176.4 and 192 kHz. It is possible to select the clock synchro method, either internal or S/PDIF input signal.
I will just relate the PCM recording through its S/PDIF input.

I used several 192kHz 24bits files to be recorded (I also used the same files when previously testing ASUS Xonar D2/PM):
• 1 file containing all possible values taken on 24 bits samples. File content: [ 0 0 1 1 2 2 ... 16777214 16777214 16777215 16777215 ].
• 1 file containing a non-null constant value during 30 minutes. File content: [ 16777215 16777215 16777215 16777215 ... 16777215 16777215 ].
• 1 file containing silence during 30 minutes. File content: [ 0 0 0 0 ... 0 0 ].
• 1 file containing real music.
Before entering test details, I found a limitation in the M-Audio drivers concerning clock synchro. WDM drivers can't be used to record while synchronizing on the S/PDIF clock, and on the opposite, ASIO drivers can't record while synchronizing on the internal clock. This limitation was hit using several recording software (Sonar, GoldWave, Audacity).

Here are the tests I conducted:

1- Recording a consumer S/PDIF PCM signal

The PCM signal was played from another computer using foobar with kernel streaming plugin.

a- Using WDM driver and internal synchro: Failure

• The problem encountered here seems to be jitter. 2 samples were sometimes added to the signal, and samples around were kind of stretched.
Here is a concrete example: playing the sequence
[ 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 ],
recording was
[ 1 1 2 1 3 3 4 3 5 4 6 5 7 6 8 7 8 8 9 9 ].

b- Using ASIO driver and S/PDIF synchro: Success

2- Recording a professional S/PDIF (aka AES/EBU) PCM signal played from the Audiophile 192 itself

The S/PDIF output has the possibility to send AES/EBU data (switch on the driver side). I directly connected its S/PDIF output to its S/PDIF input, and played using foobar and ASIO playback driver. Unfortunately ASIO driver can't be used for both playback and recording, so I could not test ASIO recording with this configuration.

a- Using WDM driver and internal synchro: Success

• No problem. Jitter can't happen as the same clock is used for both playback and recording. This test validates that the Audiophile 192's S/PDIF input accepts AES/EBU data correctly.

3- Recording a professional S/PDIF (aka AES/EBU) PCM signal played from Forssell MADC-2 output

For this test, I can't check for sure if the recording is bit-perfect as my source is analog when going into MADC-2.
However, I did not hear/see any drop-out or distortion when recording silence, sine waves or music, both with WDM driver (Internal clock) and ASIO driver (S/PDIF clock).
I suspect that WDM driver recording using internal clock synchro has induced jitter, but it was impossible to hear it.

Conclusion:

M-Audio Audiophile 192 can clearly record bit-perfectly both S/PDIF and AES/EBU signals (when synchronized on the S/PDIF signal).
Jitter was measured where it was supposed to occur (only when the source was an external device and the clock synchro was internal), nothing abnormal.

Other notes I have taken:
• Concerning the previously tested ASUS Xonar D2/PM (for consumer S/PDIF recording only), its clock synchro was certainly S/PDIF also, as I got the exact same number of recorded samples. Just the values were modified. With Audiophile 192, jitter resulted in the addition of new samples that were kind of interpolating the source signal.
• The only 2 causes of distortion I have seen along my tests were bad software drivers and jitter.
• I did neither test sample rates <192khz nor 16bits recording. I assume that if 192kHz/24bits records bit-perfectly, other formats should be ok.

If I happen to test another gear, I will continue posting my results here.

I hope those results will be helpful for others. If you want me testing specific features or configs that I may have missed, feel free to ask, I will try my best.
#37
4th July 2010
4th July 2010
#37
Lives for gear

I thought that AES had to use an smux scheme. for higher sample rates at least.

http://www.sonorus.com/audio/smux.pdf

I find it totally unsurprising that these digital connections operate so badly via computer drivers.

#38
4th July 2010
4th July 2010
#38
Lives for gear

#39
7th July 2010
7th July 2010
#39
Lives for gear

Quote:
Originally Posted by Teddy Ray
there is an easy way to see if something is "bit perfect" or not.

use a .md5 checksum

hkSFV Overview/Features
I bet chomsky manufactured your consent to say that.
#40
7th July 2010
7th July 2010
#40
Lives for gear

Quote:
Originally Posted by Muser
I bet chomsky manufactured your consent to say that.
#41
4th November 2011
4th November 2011
#41
Gear interested

hi,

Sorry for bring up a old thread. I'm trying to do bit perfect SPDIF recording, and come by this thread. Then bought a M-Audio Audiophile 192. But so far still don't know how to do this...

My setup:
PC A as spdif source, onboard spdif coaxial output, Win7 64bit, foobar2000 with wasapi plugin, 44.1khz 16bit wav dts file downloaded from Free DTS and AC-3 (Dolby Digital) Downloads - Kelly Industries output to a Pioneer receiver, receiver correctly see the spdif as DTS

PC B as spdif recorder, sound card is M-Audio Audiophile 192, Win7 32bit, sound card driver downloaded from m-audio website, in the driver panel, it sees the external spdif source correctly in 44.1khz, external spdif clock is selected and locked

I tried a few audio recording software, such as REAPER, wavosaur, Cool Edit pro etc, the resulting recorded wav file when playback on the PC A, the Pioneer receiver does NOT go to DTS and only output white noise.

Please give me some hint! Is there some specific software and/or options/settings must first configure for this to work? Thanks in advance.
Muriel Esteban
#42
7th November 2011
7th November 2011
#42
Gear interested

Hi

Here is my setup to get bit-perfect recording so far:
• PC: Intel Core2 Duo E8400 @ 3Ghz with 3,25 Gb RAM
• Sound card: M-Audio Audiophile 192
• OS: WinXP SP3 Professional 32 bits
• Sound card driver: M-Audio Delta 5.10.0.5074
• Recording software and drivers: Ableton Live Lite M-Audio Edition 8.1.3 (given with the M-Audio AP192) configured to record using ASIO driver named "M-Audio Delta ASIO" (buffer of 4096 samples).
• Recording setup (from the M-Audio Delta driver): 192kHz, 24bits, locked on external source, professional mode (AES)
With all the testing I conducted, I can say that unfortunately the bit-perfect recording depends on the hardware, drivers and recording software.

My advice to test your gear would be to use PCM files that you forge with all the values you want to record, then compare the recorded file with the source with basic hexadecimal editors.
This way you might understand the distortions applied in your recording chain. During my various hardware/software testing, I found gain distortion, jitter and even dithering! Knowing the kind of distortion you suffer from will help you point out which part of your recording chain might be the problem.

Hope this helps.

Replies
MaxPace / Music Computers
7
tmd187 / Music Computers
5
K8L-64 / Mastering forum
7
rokuez / Music Computers
4
bashville / So much gear, so little time!
2

Forum Jump

SEO by vBSEO ©2011, Crawlability, Inc.