You might want to be very specific and tell them you'd like to know how the Mytek assigns bytes for the 192 bits (24 bytes) for the channel status in the audio frame, for both the spdif outputs and the AES outputs. Tell them you are most interested in the first 2 bytes of the channel status in the audio frame in particular (again, for both their spdif output and their AES output). Tell them you are having problems with your Mytek working with your recorder and you want to get this information from both of the equipment manufacturers and ensure that both are properly addressing the relevant spdif and AES standards so that you can determine why the two units are not working together.
The bottom line is that the Mytek is marketing itself as providing an AES digital output and a spdif digital output (and to clarify, not that they are simply providing an AES output on an RCA connector). Similarly, Tascam is claiming they have a recorder that accepts a spdif digital input. If both companies are doing what they say, the units should work together. If Mytek is claiming it isn't their fault, they should provide you the above information. Frankly, I'm betting Mytek is at fault, and not Tascam (and Sony with the D50).
There probably is an issue with how they are marketing their ADC. The AES standard and the Spdif standard are not the same standard, with two different types of connectors (XLR and RCA), they are different standards with different requirements to comply. The trouble is, the standards for audio word/audio block development are very, very similar. So I can easily see that an ADC mfg might want to just comply with one standard to make it easy on themselves, but they are marketing their ADC as if it is meeting two standards and supplying 2 different outputs: AES and spdif (not just an AES signal on an RCA output, and calling it spdif).
Again, it could be either Mytek or Tascam who is at fault. The way to find out is to get them to tell you how they are assigning (or reading in the case of the recorder mfg) the channel status bytes in the audio frame.
Ok, that's not short, but that's the short story. Here's the long story:
The AES/AES3 and spdif standards are practically the same. I think the only difference is how they assign the channel status bit. As background, both AES and spdif expect a 32-bit word (or 64-bit, with 32-bit subframes for the left and right channels). Of those 32-bits, there are 24-bits of audio, leaving 8 bits (one byte) for other information. That isn't much room, so what is done is that each of those 8 bits has a different function (and one of those bits is the channel status bit).
To make these single bits useful, the audio is separated into an "audio frame" of 192 audio samples long. This provides 384 bits of information (192 samples of 2 channels each), so for each L-R channel, you get 192bits of information (24 bytes) in an audio frame. So as you are capturing audio samples (at 48k samples per second, or 96 samples per second or whatever), the single available bits in the audio word are being strung together to make useful bytes of information for each of those 8 extra status bits (beyond the 24 bits of audio).
The only difference between AES and spdif is how the Channel status "bit" is turned into channel statues information in the audio frame. Again, you're getting 24 bytes of information in the 192-sample-long "audio frame". These bytes have different meanings for AES and for spdif. The first 2 bytes are the most important, esp the first byte.
Here are the assignments for the AES channel status bytes:
And here are the assignments for the spdif channel status bytes:
As you can see, AES and spdif assign things differently for the channel status bit. A couple things to take from this: in both cases Bit 0 of Byte 0 is the bit for assigning spdif vs AES. So an ADC company that includes both an AES output and a Spdif output should be outputting 2 completely different "words" (audio samples) on those two outputs. The AES output should have Bit 0 of Byte 0 of the channel status bit of the audio sample within the audio frame set to 1 to indicate that what is being provided is an actual AES output. And similarly, Bit 0 of Byte 0 of the Channel Status 24-byte frame should be set to 0 for the digital audio stream being sent out of the RCA spdif output.
The other thing to notice in particular is Bit 2 of Byte 0: For the AES output, this bit addresses whether there is any pre-emphasis encoding of the audio signal. For the spdif output, this bit assigns whether copying (ie, reading by your recorder) is permitted, or if copying (allowing your recorder to accept the signal and record) is restricted.
Remember, this is all strung together out of 1 bit of a 32-bit long audio word, of which 24bits are audio, and the other 7 bits are all the same for both AES and spdif. So an ADC mfg might easily try to cut corners and just output the same information for both the AES output and the spdif output. And since the audio is the same for both AES and spdif, they feel that the Recorder mfg should just ignore this channel status stuff and allow copying (recording the digital audio).
It could be the Recorder mfg is "at fault". But if the ADC company is not sending out a Channel status frame with Bit 0 of Byte 0 set to 0, then they are not sending out a true spdif signal, they are sending out an AES signal. And if they do set that bit to 0 for spdif and aren't sending a signal of 1 of Bit 2 of Byte 0 of the Channel Status frame (the copy restrict/permit bit), then they are saying they have a Spdif output, but the spdif output they are sending is telling recorders not to record the signal that is being provided (which would be pretty stupid -- hey, here's an audio signal I'm providing, but you shouldn't allow it to be recorded).
Bottom line to all this: you should get Mytek to provide you what is being assigned, for the digital audio stream being output on their "spdif" output, to Bit 0 of Byte 0 of the Channel status frame, and Bit 2 of Byte 0 of the Channel status frame. If they are not 0 and 1 respectively, then they are not providing a true Spdif output as they are advertising on their ADC192, and they should upgrade their firmware to correct the problem, and/or should stop marketing their ADCs as providing and refund the money of customers who bought their ADCs expecting a true spdif output when the ADCs were not providing it.
And if Mytek is providing all of that correctly and correctly implementing the spdif standard, then turn that all around: get with Tascam and find out how they are treating the Channel status frame with their recorders and if it isn't meeting the spdif standard, then they need to fix the problem, or stop their false advertising and refund money to consumers.
This finger-pointing is total BS. There are standards in place to insure that equipment from different manufacturers works together. If any two pieces of equipment are not working together, they are either faulty or the mfg is not implementing the standard correctly. It isn't good enough to say close enough (as in, close enough, I'm provding an AES signal and calling it a Spdif signal since I send that signal to a RCA connector), other companies should deal with it. If you say you provide (or accept) an AES and/or a Spdif digital signal, then you are either doing it completely or you are providing false claims to the consumer.
Topic: Tascam DR100 MKII (as Bit Bucket) and Mytek Stereo192 ADC - Incompatable? (Read 24091 times)