The fact that I am presenting computer constructed PCM data to the interface allows me to validate the chain from source to recorded file by being able to detect something as subtle as a single bit error. This may in fact be a bug that has flown under the radar as a sample variation of 1 would not typically be detectable, or would be obscured with dither. So I am here hoping that someone from Steinberg development see this and may be able to provide some insight on if there could be a bug in WL with respect to this. But, further analysis of the captured 24-bit samples from Ableton exposed some other issues and I am not completely sure I can use it as a gold standard. When I was able to get samples with all LSB=0x00 from Ableton Live I immediately directed my suspicion on WaveLab. I would really like to diagnose and completely rule out that this data is not being inserted by the interface or the drivers and in order to do that I would need to interface directly with the ASIO driver to see what exactly is being presented by the audio interface – at present I don’t know what I can use to diagnose this. Specifically, the issue I am concerned about is the injection of the LSB=0x01 into the 24-bit session for the negative samples of 16-bit PCM SPDIF stream as captured by the WaveLab software. I present this situation and my observations to the community here to see if anyone can provide some insight into what I am seeing or can provide a suggestion to assist in diagnosing further. The columns of the above are defined as per:ī : left channel sample value in hex (big endian format, 3 bytes for 24-bit, 2 bytes for 16-bit)Ĭ : left channel sample polarity indicator ^ - positive, v – negativeĮ : right channel sample value in hex (big endian format)į : rightt channel sample polarity indicator ^ - positive, v – negative Here are some samples from a 24-bit session and the resultant save to a 16-bit file. The following is some output samples from a PCM diagnostic tool I use. At first I thought the issue was manifested from the word length reduction, but after extensive analysis of the content of samples I determined that the sample length reduction for 16-bit sessions or 24-bit sessions saved as 16-bit was a simple integer divide by 256 algorithm, and as such the bogus LSB of 0x01 would skew the result vs a simple right shift LSB truncation. When 24-bit samples are having the LSB set to 0x01, and the session is recorded as a 16-bit session, or recorded as a 24-bit session and saved as 16-bit, the saved samples are skewed by -1 as a resultant of WaveLab’s word length reduction algorithm. So I redid the recording as a 24-bit session and examined the saved samples. The issue was discovered as I was recording a session at 16-bit and discovered that the recorded samples did not match the samples in the SPDIF PCM stream. Focusrite tech support has advised that when 16-bit PCM is fed into the SPDIF in of the 6i6, that the interface will left shift the samples and zero fill the LSB with a 0 byte so that it can be transferred as a 24-bit sample. The Focusrite’s interface to the DAW is always 24-bit. I think that this error is manifesting in the WaveLab software as this does not happen with Ableton Live. All samples should have a LSB = 0x00 according to Focusrite support. For samples with a positive value, the LSB is always = 0x00. When recording a 24-bit session of a 16-bit PCM stream being fed to the Scarlett 6i6 via SPDIF in, I am getting recorded samples that have a least significant byte (LSB) = 0x01 on samples with a negative value (below center axis). Audio Interface: Focusrite Scarlett 6i6/ASIOīyte ordering in this discussion will be big-endian.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |