ran this tonight w/ no problems at all. no clicks or dropped signals. hmmm, interesting. sbm1 coax mod>co2>jb3
Im trying scare up the original tests that started this devices bad rep...stay tuned...
I dont see them - not much there - am I missing something...?
The Thing before the CO2 is the variable...why point the finger at the CO2?
I just dont get it the logic here...
TASCAM PE-120x3 > Nakamichi Mx-100 > Midiman Flying Calf 24bit > Midiman CO2 > Creative Nomad Jukebox 3(x3)
http://www.pennmar.net/new%20nomad%20testing-1.htm
I resaved the Excell file as html...not sure if that helps...
FAIL | V3 SPDIF > CO2 > POC15AB > JB3The only device with which it succeeded more than once is the AD2K. And that's only 6 hrs of testing. Given that some of the other tests indicated only a few dropped or misplaced samples, it's entirely possible - likely, even - the AD2K > CO2 combo may prove bit-imperfect with additional testing
FAIL | V3 AES > transformer > CO2 > POC15AB > JB3
SUCCEED | V3 AES > transformer > CO2 > POC15AB > JB3
FAIL | V3 AES > transformer > CO2 > POC15AB > JB3
SUCCEED | AD2K > CO2 > POC15AB > JB3
SUCCEED | AD2K > CO2 > POC15AB > JB3
FAIL | R500 > CO2 > POC15AB > JB3
FAIL | R500 > CO2 > POC15AB > JB3
FAIL | R500 > CO2 > POC15AB > JB3
Also...still curious about your Flying Calf > CO2 > JB3 setup...
Truncated by the JB3
Truncated by the JB3 - anything I can do in post to improve what the JB3 records...? I always have used the 44.1 setting.
My conclusion from the sample data:the CO2 is not bit-transparent[/list]
Do you come to a different conclusion?
Truncated by the JB3
Ouch! My understanding is that the Nomad does a major hack job on the truncation process.
Truncated by the JB3 - anything I can do in post to improve what the JB3 records...? I always have used the 44.1 setting.
Not that I'm aware of, no. I thought they made a 16-bit Flying Calf at some point...or something similar...maybe swap out the FC24 with a 16-bit ADC?
To be more specific
todmodsbm w/coax mod, using the cox mod jack>spdif cable>input on co2 (the middle setting on the co2)>optical cable>jb3
worked
todmodsbm>oade active cable>d100
>oade active cable>co2 (third setting)>jb3
cracks and pops
My conclusion from the sample data:the CO2 is not bit-transparent[/list]
Do you come to a different conclusion?
I've always suspected that Jamie's errors were actually the result of the JB3 > USB > computer path and not the result of the source > CO2 > JB3 path. It's not like the CO2 processes the bits or anything like that. It's a format converter. If the input is high, it turns the TOSLINK's LED on. If the input is low, it turns the TOSLINK's LED off. It's accomplished with logic gates, not buffers and processors, etc... The only way I can imagine the CO2 appearing to be anything but bit perfect is if it does not turn the LED on bright enough to reliably detect the 1's in the data at the optical S/PDIF receiver in the JB3.
By the way, I'm not questioning Jamie's integrity. I'm just questioning whether he really tested what he thought he was testing. Everyone that I know of that has used a CO2 has had good results. And if I remember correctly, Jamie gave up on the JB3 before he was able to verify that the JB3 was bit perfect itself.
Bean, of the two of us, I'm the one with the clue. I'm an electrical engineer with over 25 years of experience at circuit design.I've always suspected that Jamie's errors were actually the result of the JB3 > USB > computer path and not the result of the source > CO2 > JB3 path. It's not like the CO2 processes the bits or anything like that. It's a format converter. If the input is high, it turns the TOSLINK's LED on. If the input is low, it turns the TOSLINK's LED off. It's accomplished with logic gates, not buffers and processors, etc... The only way I can imagine the CO2 appearing to be anything but bit perfect is if it does not turn the LED on bright enough to reliably detect the 1's in the data at the optical S/PDIF receiver in the JB3.
By the way, I'm not questioning Jamie's integrity. I'm just questioning whether he really tested what he thought he was testing. Everyone that I know of that has used a CO2 has had good results. And if I remember correctly, Jamie gave up on the JB3 before he was able to verify that the JB3 was bit perfect itself.
are you serious ??? you haver NO CLUE what the hell youre talking about :P
its a format converter alright but it IS transferring bits, hence why we like BIT PERFECT things
usb is sending the info THATS ALREADY BEEN WRITTEN, usb and firewire are just interfaces to send data, nothing more, nothing less, they dont have to be bit-perfect because it the devices did theyre job CORRECTLY already, then the info theyre sending is BIT-PERFECT
are you serious ??? you haver NO CLUE what the hell youre talking about :P
its a format converter alright but it IS transferring bits, hence why we like BIT PERFECT things
usb is sending the info THATS ALREADY BEEN WRITTEN, usb and firewire are just interfaces to send data, nothing more, nothing less, they dont have to be bit-perfect because it the devices did theyre job CORRECTLY already, then the info theyre sending is BIT-PERFECT
Bean, of the two of us, I'm the one with the clue. I'm an electrical engineer with over 25 years of experience at circuit design.........
Bean, of the two of us, I'm the one with the clue. I'm an electrical engineer with over 25 years of experience at circuit design.I've always suspected that Jamie's errors were actually the result of the JB3 > USB > computer path and not the result of the source > CO2 > JB3 path. It's not like the CO2 processes the bits or anything like that. It's a format converter. If the input is high, it turns the TOSLINK's LED on. If the input is low, it turns the TOSLINK's LED off. It's accomplished with logic gates, not buffers and processors, etc... The only way I can imagine the CO2 appearing to be anything but bit perfect is if it does not turn the LED on bright enough to reliably detect the 1's in the data at the optical S/PDIF receiver in the JB3.
By the way, I'm not questioning Jamie's integrity. I'm just questioning whether he really tested what he thought he was testing. Everyone that I know of that has used a CO2 has had good results. And if I remember correctly, Jamie gave up on the JB3 before he was able to verify that the JB3 was bit perfect itself.
are you serious ??? you haver NO CLUE what the hell youre talking about :P
its a format converter alright but it IS transferring bits, hence why we like BIT PERFECT things
usb is sending the info THATS ALREADY BEEN WRITTEN, usb and firewire are just interfaces to send data, nothing more, nothing less, they dont have to be bit-perfect because it the devices did theyre job CORRECTLY already, then the info theyre sending is BIT-PERFECT
The fact is that the CO2 is just logic gates(inverters, probably of the 74HC04 variety), an LED and a phototransistor. It does not interpret the data that comes into it. If it receives a logic high level on its S/PDIF input, it applies current to the LED on the optical output. When that logic level goes low, it quits applying current to the LED. Simple as that. There is no way to screw that up, unless the LED is not turned on bright enough to be detected by the optical input to the JB3. If the CO2 does not produce bit perfect transfers through the TOSLINK (S/PDIF optical) port, then this is the only thing that could cause the problem.
The other fact is that USB transfers are not always bit perfect, especially if you are hooked up to an AMD Athlon-based computer that's about 3 to 5 years old. The VIA chipset used in those things is notorious for buffering errors. If you don't get a good transfer out of the JB3, the resulting file will have errors. Simple as that. (Why do you think that people sometimes have problems with firmware updates through the USB port? Hint: it's related to the fact that the transfers through the USB port are not always bit perfect.) On other machines, similar problems can occur on the firewire interface. Whatever computer you use, it's important to verify that multiple transfers of the same file will reliably produce multiple files with identical contents.
What I dont get is how any SPDIF/AES signal can be 100% bit perfect...?
It may be like 99.99999% bit perfect - but not 100%
Since SPDIF is a streaming format - there is no "handshake" between the two devices...Its a one shot deal...Device A just assumes that Device B got the message...so there is always the possiblilty of error, however low it may be.
With USB (and I presume Firewire), there is a handshake, and Device A gets to make sure Device B got the correct data...at least in theory (re: SparkE!)
If it receives a logic high level on its S/PDIF input, it applies current to the LED on the optical output. When that logic level goes low, it quits applying current to the LED.
unless the LED is not turned on bright enough to be detected by the optical input to the JB3. If the CO2 does not produce bit perfect transfers through the TOSLINK (S/PDIF optical) port, then this is the only thing that could cause the problem.
The other fact is that USB transfers are not always bit perfect
More of:
[1] anecdotal problems people have encountered with the CO2 in the signal path
With USB (and I presume Firewire), there is a handshake, and Device A gets to make sure Device B got the correct data...at least in theory (re: SparkE!)I think that the bit integrity part of the interface is actually left to the drivers for the device. So, the interface to a hard drive or Flash Card reader/writer will likely use drivers that at least run a CRC checksum. But that's not necessarily the case for the drivers for the JB3. (I don't know if the JB3 drivers do any data integrity checking, but I suspect not.) One thing's for sure, they don't handshake bit-for-bit by sending back a copy of what was received. That would slow the interface down to at least 1/2 its speed simply because the same data would go across the interface twice, once to the destination and once to come back for verification.
Not sure if it helps - but here's one inside shot...What's the part number on that chip just to the right of R4? Would you be willing to take a shot at the backside of the board?
I've noticed a tendency among tapers to accept anecdotal evidence regarding equipment failures as proof of cause and effect. Not all accidents in life involve clear cut cause and effect relationships.
I've also noticed that there is a tendancy among tapers not to attempt to truly isolate the cause and effect relationships that DO exist.
So, is that situation the fault of a weak optical transmitter on the CO2 or is it the result of a poorly designed optical receiver on the JB3 or is it the fault of a badly fitting optical cable or is it the fault of something else altogether?
But that does not necessarily mean that someone cannot get bit perfect results with the CO2.
So, is anyone out there willing to work with me to investigate what are the real differences between the ODL-276 and the CO2?
figured it was best to disassemble gear after show...
What is bit transparency...?
What is your standard for something to declared "Bit Transparent"
Also Im a bit unclear as to what qualifies as a test...
Can I do this with a CD player with digital out?...I dont have a PC with digi out...
Can I do this with a CD player with digital out?...I dont have a PC with digi out...
Hmmmmm...maybe, but then you'd have to ensure your DAE of the WAV from the CD is perfect as well, not a super-easy task unless you already have EAC set up to do so properly. And, at any rate, it wouldn't actually prove the CO2 is bit-transparent in the field with your particular gear, which IMO is the real question.
I wonder if you burned the wavs as data - do some DVD players read that kind of disc...as if they were mp3s?
Isn't it true there is a great deal of variation in the implementation of SPDIF spec?
Is there anything one can look for in an existing recording to detect any problems?
Wouldnt some software complain if there were samples missing?