You are not logged in. Please login or register.
RME User Forum → ADI-2 & 2/4 Pro series, ADI-2 DAC series → 16-Bit-test is not equal to HEX-compare
I was play&record 16bittest files to the digital domain only. When I play recorded files it shows 16bit test as passed. RME's display always shows 16bit test as passed to the both ways (AES<->USB).
But when I make HEX-compare between original and recorded WAV-files (https://www.fairdell.com/hexcmp/) it doesen't looks bit-identical even after offset. So what kind of bit identity we are talking about?
Play back the 16 bit test file and record it via digital loop, then play back the recorded file. A proper software (like my stone-age old WaveLab version) will cause the bit test passed message to show up, even at 24 bit (max bit res supported via digital I/O). All the rest is not our problem...
yes, i made the same - your 16 bit test is passed
but HEX-editor and Foobar's bitcompare utilities shows differ both
maybe its caused by 24bit I/O architecture path where 16bit signal sends as 24bit with additional zeros?
I guess was right
When I repeat loop-recording for 24bit audio it shows full identity in my HEX-comparator
But still not for 16bit data - every pair of bits always has offset
when i try to set shift between one pair of bits - next pair of bits has new zero offset again
Well, next news - it depends from kind of diigital transport.
Most of modern USB/SPDIF converters like SOtM always uses 24 bit path for 24 bit or 16bit both. In this case RME shows 16bit tests as passed but this is not bit-to-bit stream actually.
It must be a 16bit only transport like Airplay Express then we have full bit-identity.
To make a clear statement: The 16 bit test passes and the signal IS fully 16 bit to bit identical. That is all it says, and the test is correct and works.
If you have additional bits outside the 16 bits and want to check for those you have to use a 24 bit test.
manual says -- The Bit column shows the amount of bits found in the SPDIF and AES audio signal. Note that a
24 bit signal that is shown as 16 bit is indeed 16 bit--
Thats why Bittest says 16bit test is passed even on 24bit path
You just do not take into account the zero data, unlike HEX-comparator
We don't have to take any 'zero data' into accunt, as it is not what the bit test is about. The Bit column has some limitations and is totally unrelated to the Bit Test. And if the bit test says 16 bits passed then 16 bits are absolutely bit-identical. It says just that, nothing else.
As I told you I feed AES/SPDIF inputs of RME and made records of bittest files via USB.
ADI's display always shows bittest is passed. When i play all these records ADI's shows the same - bittest is passed.
Believe me or not, but HEX-editor is not a kind of "magic tools". This is a most transparent (and primary) way to see what's is changing on audio data, no jokes. You just looking on table of binare codes. Its simple. Then i put original and recorded audio to the HEX-editor and apply offset because length of files not equal.
I have no issues with 24bit audio, recorded from output of SOtM tX-USB. I have no issues with 16bit audio, recorded from optical output of Airport Express. After offset apply tables of bits stays the same, no difference from originals. Except one case!
I have difference between original and recorded files only when i use SOtM tX-USB as source for playback 16 bit audio. It was recorded as 16 bit already. When you look on HEX-tables of recorded files you can easy find аdditional zero words between original bits. So tables of bits was changed actually. Anyway, even whan i play recorded files, ADI will show - 16bit test is passed however. Thats I just want to note.
So you found out that the SOtM tX-USB drivers can not loop playback correctly and add some samples on stop or start? And the added zeroes you talk about are not within the 16 bit test signal but added between repeated playbacks of this test signal, hence not part of the 16 bit test?
No, of course, I do not take into account the zero samples at the start and end of the recording. For this, there is an offset in the HEX-editor. To be able to set and compare exactly the start of the actual array of "useful" audio data.
So its not about start and end, I was talking about changes inside audio data only. I can send this record or show another screenshots from HEX-tables. Being played, new records lights "16bit passed" on the ADI's display, but in fact it has some differs from the original file. And this is not the lenth.
You say data is changed - then the bit test would fail. You say zeroes are added (offset) - yet you claim the length hasn't changed.
Note the bit test is a very short sequence (the click sound) which is simply repeated to make the file more long. Only the click sound is relevant and checked.
Look at the HEX-tables in Little Endian Format.
Here is start of recorded (above) and ofiginal files after offset apply. No red on the tables - all bits&cells are coincide.
Let's going down
Now we have "red" cells were date are not coincide. You can see same symbols but it filled on different cells now. I have no idea how DAC deal with it, maybe it not important, but it looks not "equal" on the level of binary code.
That is still not the point. The 16 bit test is triggered by and reads the special, very short bit sequence. This one is repeated multiple times. If your recording includes the correct bit sequence only one time the message will come up and stay for 2 seconds on the display. When there are more tests and fail within these two seconds you won't see them. Once again: this is a bit test, not a playback/recording/offset whatever test. You should do a more precise analysis on your recorded file to find out how many valid test sequences it includes and what exactly happened to the others.
I was play recorded file recently - message was stay for 5 seconds
Please read again (and try to understand) my post 14. If you play a single test sequence (the click sound, duration of sequence is 100 ms), the display will show the message for 2 seconds. The display of the message is not cancelled by anything and retriggered after 2 seconds for another 2 seconds if the valid test sequence is detected again, and so on.
RME User Forum → ADI-2 & 2/4 Pro series, ADI-2 DAC series → 16-Bit-test is not equal to HEX-compare
Powered by PunBB, supported by Informer Technologies, Inc.