Topic: co2>jb3

[bagtagsell]

ran this tonight w/ no problems at all. no clicks or dropped signals.  hmmm, interesting. sbm1 coax mod>co2>jb3

[F.O.Bean]

ran this tonight w/ no problems at all. no clicks or dropped signals. hmmm, interesting. sbm1 coax mod>co2>jb3

nice!

ive heard many times its flaky at best tho, and its not bit-perfect, you just cant hear the dropped samples

[hexyjones]

Im trying scare up the original tests that started this devices bad rep...stay tuned...

[hexyjones]

well - if you search DAT heads I can find only this

From: "Jamie Lutch" <jlutch@altairinc.com>
Subject: midiman co2 may not be bit-accurate/ jb3 progress
Date: Sat, 5 Oct 2002 23:17:28 -0700

in the neverending quest to test the nomad jb3, I picked up a midiman co2 to
test as the coax>optical converter I need before the unit. for those who
arent familiar with it, it is a 9vdc powered little box that can take coax
in and spit out both coax and optical. I did 3 tests with it, they were all
horrendous, causing  lierally 100's of short spikes of a few samples in the
recording, many of which were audible as pops and clicks. this happened on
both the coax out (to the vx) and the optical out (to the jb). I switched
back to my other coax>optical converters, both get me to 'near-bit
accuracy' (jb limited at this point) The performance was so bad with the
co2, I'm going to have to consider the possibility that the unit might be
defective. I'll try to get my hands on another unit to test (anyone have one
of these? I'll pay shipping both ways, and will only need it for a day or
so).

I know some people were considering purchasing these to use with the
jukebox. For now, I would hold off until more data becomes available. There
are other $20 that can convert coax>optical (tho they are dead-enders, and
dont allow for the continuation of a digi chain)

wrt the jukebox, a few other tapers have got them now, were going to pool
together and compile a database of transfer info to try and isolate the
problems of the jb3, which so far seem to be random and non-repeatable. so
again, for those considering purchasing a jukebox for recording, I'd hold
off a bit till more data becomes available

He also refers to this JL post
http://www.solorb.com/dat-heads/digests/V6.500/D577#Msg21

There is some claim about Lutch tests in the NJB3 tapers yahoo group...but I cant find them in their archives or files section.

From the taperssection JB3 FAQ: (- but no such files exist...)

Jamie Lutch has posted some testing results over on the NJB3Tapers Yahoo group Files section...


Anyone have these elusive testing results...

[Brian Skalinder]

Im trying scare up the original tests that started this devices bad rep...stay tuned...

FWIW, Jamie posted his test results in the NJB3Tapers Yahoo group, files section.  Not sure why you could'nt find 'em.  Unfortunately, I can't check right now as the proxy server at this office blocks my access.

[hexyjones]

I dont see them - not much there - am I missing something...?

[Brian Skalinder]

I dont see them - not much there - am I missing something...?

See attached...

[hexyjones]

Yeah found that - He never does test:

sinewave>V3>AES>canare 100-75 ohm transformer>greybox>sony poc15ab>nomad

Results 15-19 - The Thing before the CO2 is the variable...why point the finger at the CO2?

I just dont get it the logic here...

[Brian Skalinder]

The Thing before the CO2 is the variable...why point the finger at the CO2?

I just dont get it the logic here...

I suspect that Jamie varied the devices upstream in an attempt to isolate the CO2.  Which is more likely - that all three variables in the test (the components before the CO2 in the signal path) are independently bit-imperfect, or that the CO2 as the common thread is likely bit-perfect?  I would argue the latter is more likely.

I can't access the tests so I'm unable to see exactly what Jamie's tested.  But for me, it doesn't matter whether Jamie's proven conclusively that the CO2 is the problem.

Given:

[1]  anecdotal problems people have encountered with the CO2 in the signal path
[2]  no one has proven definitely some other device in the chain causes the problems
[3]  no one has proven the CO2 is truly bit-transparent

I don't see how we can make a determination one way or the other.  However, it seems reasonable to suspect the CO2 as the, or at least a culprit given the anecdotal experiences.  It's clear to me that sufficient doubt exists regarding the CO2s capabilities to operate bit-transparently.  I, for one, won't trust the CO2 unless/until someone demonstrates with definitive testing that it does, in fact, operate bit-transparently.  Bottom line:  no one has proven the CO2 is bit-transparent.

On a side note, I see you're running:

TASCAM PE-120x3 > Nakamichi Mx-100  > Midiman Flying Calf 24bit > Midiman CO2 > Creative Nomad Jukebox 3(x3)

Does the Flying Calf 24-bit ADC have an option to dither to 16-bit, or is the JB3 truncating your signal?

[hexyjones]

http://www.pennmar.net/new%20nomad%20testing-1.htm

I resaved the Excell file as html...not sure if that helps...

[Brian Skalinder]

http://www.pennmar.net/new%20nomad%20testing-1.htm

I resaved the Excell file as html...not sure if that helps...

Thanks, that helps.  Summarizing Jamie's tests:

FAIL    | V3 SPDIF > CO2 > POC15AB > JB3
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

The 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

My conclusion from the sample data:

the CO2 is not bit-transparent[/list]

Do you come to a different conclusion?

Also...still curious about your Flying Calf > CO2 > JB3 setup...

[hexyjones]

Also...still curious about your Flying Calf > CO2 > JB3 setup...

Truncated by the JB3 - anything I can do in post to improve what the JB3 records...? I always have used the 44.1 setting.

A/D Type: 24-bit, delta-sigma, 128 x oversampling.
Sample Rates: 48 kHz or 44.1 kHz.
Dynamic Range: 105 dB (A-weighted).
THD + Noise: .002%, -94 dB (A-weighted).
Nominal Input Signal: -10 dBV (standard input level setting).
-16 dBV (“+6” input level setting).
Full-scale Input Signal: +6 dBV (standard input level setting).
0 dBV (“+6” input level setting).
Frequency Response: 24 Hz to 22 kHz (+/- 0.2 dB).
Input Impedance: 10 K ohms minimum.
Analog In Connectors: 1/4” female TS-type, unbalanced.
Digital Out Connector: RCA, female.
Digital Out Format: S/PDIF, transformer-coupled.
S/PDIF SCMS: May be enabled or disabled.

[bluegrass_brad]

Truncated by the JB3

Ouch!  My understanding is that the Nomad does a major hack job on the truncation process.

[Brian Skalinder]

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?

And still curious on this one, too:

My conclusion from the sample data:

the CO2 is not bit-transparent[/list]

Do you come to a different conclusion?

[hexyjones]

Truncated by the JB3

Ouch!  My understanding is that the Nomad does a major hack job on the truncation process.

How would this manifest itself? I certainly haven't picked up on any noticeable ugliness...

Maybe someday someone with a laptop will come along and I can get capture something in 24 bit - 

[hexyjones]

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?

They made a 20 bit version...maybe 2 bits of truncation is better?

[SparkE!]

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.

I personally do not trust the USB interfaces on Athlon-based computers that use the VIA chipset that was common on Athlon-based machines about 4 years ago.  I've spent hundreds and hundreds of hours fighting with my Abit KT7A-RAID machine that has that chipset in it, specifically because I could not reliably get a good transfer into the machine.  The VIA southbridge chip on that design handles all USB, IDE and ISA traffic and when you put a continuous stream through any of those paths, it drops samples occasionally.  Lots of other computers using that same chipset had the same problem.  My dropped sample problems all went away when I built my new computer around a motherboard that used a 100% Intel chipset.  Until that time, I was questioning every other piece of equipment that I had.  Turns out that everything else worked fine.  It was the computer that was screwing up.

[bagtagsell]

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

[hexyjones]

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

In that setup - the CO2 switch shouldn't make a difference...but I wonder if the active cable looks different to the CO2...

Whats an active cable? - detects I or O?

[hexyjones]

My conclusion from the sample data:

the CO2 is not bit-transparent[/list]

Do you come to a different conclusion?

More of:

[1]  anecdotal problems people have encountered with the CO2 in the signal path

[F.O.Bean]

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

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

[SparkE!]

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

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.

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.

[Brian]

are you serious you haver NO CLUE what the hell youre talking about

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.........

+T for the informative posts on this subject SparkE!

-Brian

PS:  just messin' with ya bean

[F.O.Bean]

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

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.

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.

i actualluy really ap[preciate that info, but what doesnt make sense is, weve all tested the hosa digital format converters, and upon testing ONLY the Hosa boxes, they seem to be the ONLY ones that are consistently bit-perfect

so im def not calling you a liar or anything, but when converting digital formats(ala coax(spdif)/aes>coax(optical), youre DEF dealing w/ bits being transferred, so thats why some recordings have clicks/pops, and some dont, its really a luck of the draw, some get lucky and CANT hear dropped samples, some CAN hear dropped samples that are common as hell in the CO-2

so really my questuion to everyone who asks this question all of the time, 'why not just buy the hosa and spend 50-70 bucks on it and be done w/ it, that way youre 100%  sure youre getting BIT-PERFECT transfers, ALL OF THE TIME

ive personally done hundreds of dat>odl-276>jb3 transfers and theyre all bit-perfect, its a proven combination, so why not use it

otherwise, just get an opti-mod v3 like i have and just run BIT-PERFECT from mics>v3>jb3 no worries there at all, grace rawks

[hexyjones]

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!)

[F.O.Bean]

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!)

well, do some extensive testing(which has already been done) and if the end copy from the original is 100% BIT-PERFECT, then that proves that the hosa boxes are BIT-PERFECT and that the usb/firewire transfers are too

do some testing to prove that the old tests arent correct, otherwise, believe everyone that has done so, i always liked knowing my tapes were gonna be bit-perfect and/or pop/click free

[Brian Skalinder]

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.

Another factor possibly in play:  not all devices follow the S/PDIF standard with respect to logical 1 voltage output.  So, some devices may not match well with the CO2 (or any other DFC, for that matter, depending on exactly what voltage/tolerance the DFC is set to read a logical 1).  Which ties into your next statement:

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.

And may also help explain the anecdotal variations in experience - some experiencing problems with certain gear, others not with other gear.

The other fact is that USB transfers are not always bit perfect

What about firewire?  I performed my > 70 hrs testing with the Hosa ODL-312 transferring JB3 > PC via firewire.  Unfortunately, Jamie's XLS doesn't indicate whether he transferred via USB or firewire.

More of:

[1] anecdotal problems people have encountered with the CO2 in the signal path

Fair enough, reasonable people may come to different conclusions based on inconclusive evidence.  But the simple fact remains:  while no one has proven the CO2 bit-imperfect, no one has proven the CO2 is bit-transarent in any combination of gear whatsoever.  Which IMO should still raise unacceptable doubt in the minds of those concerned about bit-transparency.  As long as you're happy not knowing whether your recordings contain artifacts due to the DFC, press on with your current gear.

Aren't any of the CO2 users out there interested enough to find out for certain by testing themselves?  I'd really like to see someone to replicate my ODL-312 testing with the CO2.  Any of the CO2 users out there want to give it a shot? 

[SparkE!]

Guys, my point is that 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'm reminded of the story about the guy that heard that most people die in their sleep and so decides never to sleep again.)

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.

In the case of the CO2 vs. ODL-276, I think that there is probably some inherent design differences that make one design more likely than the other to adequately modulate the optical output of the TOSLINK port so that a connected device can receive the bit stream, unaltered.  And I think that in most cases, the ODL-276 probably does a better job.  (That's why I own a ODL-276 rather than a CO2.)  But I don't think it's likely that the CO2's design is inherently flawed in some fashion as to actually introduce errors or gaps into the bit stream.  I believe it's more likely an issue that the optical bit stream is not accurately received by the JB3 when the optical bit stream has been produced by a CO2.  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?

My (unsubstantiated) guess is that of the two converter boxes, the CO2 produces a lower average optical power output or that there is too little difference in optical output power between a "1" and a "0" in the bit stream.  But that does not necessarily mean that someone cannot get bit perfect results with the CO2.  In fact, it has been my experience that the CO2 generally works well (though I'll admit that I'd be reluctant to take a patch from a CO2 until I know for sure what tends to causes the errors that people have associated with the use of 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?

[hexyjones]

Not sure if it helps -  but here's one inside shot...

[SparkE!]

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.

[SparkE!]

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'm headed out the door right now. I'll check back in a couple hours or so.)

[SparkE!]

Here's internal shots of the ODL-276.  By the way, I'm not terribly impressed with the workmanship on this thing.  The solder job is awful and they didn't clean the flux off when finished.  Also, there are traces that are not well adhered to the board.  I'm going to take preemptive action and solder wires in place of some of the traces before I reassemble the thing, especially the ones going to the TOSLINK ports.  Those were really loose and it would be just a matter of time before they broke from normal use.




As you can see, this is one of the designs that just uses inverters (74HC04-style) for drivers.  That type of design is usually quite reliable as long as they are assembled well.

I don't know what that chip is in the CO2 design, but that's a pulse transformer at the upper right of corkscrew's picture.  They use those transformers for compatibility with the AES-BEU signals.  It just converts the differential input signal on the RCA jack to a single ended signal.  That particular pulse transformer was designed for use specifically for use in circuits from Crystal Semiconductor that are involved with the transmission/reception of S/PDIF signals (ie. the CS8401 and CS8402, both of which have more than 8 pins - I'm not sure what that 8 pin IC is...).

[SparkE!]

Here's a shematic for the ODL-276 that I drew up today:
(Does anyone have a schematic for the CO2?)

[hexyjones]

Thanks  - I'll chime back in shortly...had a gig last night...figured it was best to disassemble gear after show...

[Brian Skalinder]

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.

True enough.  But the volume of issues with CO2 users indicates to me that trouble exists within a wide variety of gear combinations, regardless of whether or not the CO2 is the culprit.  And what amazes me is people still don't test their gear.

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.

And agreed again.  I just don't get why anyone would want to use a DFC and *not* test it, personally, for bit-transparency with their combination of gear.  Not necessarily to rule out the DFC as the problem, but simply to identify whether a problem exists, and if it does, then drill in to identify the source of the problem.

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?

Who knows, excellent point.  The point I'm trying to make is that it doesn't matter which device is at fault, necessarily - the problem exists with that particular combination of gear, for one reason or another.  Doesn't demonstrate cause > effect, but does suggest to me, anyway, that anyone running one (or any other DFC, for that matter) should make certain through rigorous testing that they aren't experiencing similar problems.  In the face of significant anecodotal evidence indicating bit-transparency problems with various combinations of gear - including the CO2 - I'm amazed people don't actually test their setups.  Shoot, I'd test my setup all over again if I switched from the OLD-312 to the -276!  And I did test all over again when I got my V3 optical mod, b/c even though I trust the Grace folks to do fine work, I wanted to know for myself whether the optical output mod was bit-transparent.  (It is, with my combination of gear.)

But that does not necessarily mean that someone cannot get bit perfect results with the CO2.

Yeah, fair enough, I should amend my previous statement to:

[1]  The CO2 is not bit-transparent with certain gear combinations, and the CO2 may or may not be the culprit.
or
[2]  No one has proven the CO2 bit-transparent with any combination of gear, so take your chances.

So, is anyone out there willing to work with me to investigate what are the real differences between the ODL-276 and the CO2?

Betcha $5 no one does this, much less get to the bottom of whether or not the CO2 is, in fact, the culprit. 

figured it was best to disassemble gear after show...

A wise choice!

[hexyjones]

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...

[Brian Skalinder]

What is bit transparency...?

Bit-transparency = the device (or devices in the chain) do not modify any of the samples within the bitstream, i.e. passing a WAV through the device chain over and over again always yields exactly the same output WAV as input WAV.

What is your standard for something to declared "Bit Transparent"

I'm not sure who you're asking, but my personal standard:  if I test it and it proves bit-transparent with my combination of gear.  Or if someone else performs sufficient testing with appropriate documentation and rigor.

Also Im a bit unclear as to what qualifies as a test...

It depends on your gear.  The simplest test would be something like this:

[1]  Identify WAV₁ on your PC
[2]  Stream WAV₁ from your PC through your known bit-transparent soundcard using S/PDIF
[3]  Pass the S/PDIF WAV₁ into the CO2 S/PDIF connector and out the CO2 optical port
[4]  Record the CO2 optical output onto a JB3
[5]  Copy the new WAV on the JB3 back onto the PC as WAV₂
[6]  Trim WAV₁ and WAV₂ to the same starting/ending sample
[7]  Compare WAV₁ and WAV₂ with a WAV compare utility, like the one in EAC
[8a] If the WAV compare returns no results, i.e. no differences between WAV₁ and WAV₂, then this particular test demonstrated bit-transparency for the gear combination involved
[8b] If the WAV compare returns results, i.e. identifies differences between WAV₁ and WAV₂, then this particular test demonstrated the gear combination involved is not bit-transparent

However, a single test run is not sufficient, IMO, and we must perform this test over and over and over again.  How many times over?  I dunno, we probably all have different standards that we would consider appropriate.  And, of course, the above test does not take into account the particular gear one would use in the field.  So if we proved the above combination of gear bit-transparent, it would not necessarily follow that if we replace the PC with a field ADC we would achieve the same results.

And so, testing field gear is even more difficult, and requires that the field ADC have two outputs - one to produce a control WAV, and the other a test WAV.  In my case with the ODL-312, I ran my field gear as though I was, well, in the field, and determined that with my gear, in the field, the ODL-312 proved bit-transparent.

[hexyjones]

Can I do this with a CD player with digital out?...I dont have a PC with digi out...

[Brian Skalinder]

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.

[hexyjones]

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?

[Brian Skalinder]

I wonder if you burned the wavs as data - do some DVD players read that kind of disc...as if they were mp3s?

Dunno.  I know mind doesn't, but it's sorta old.  But again, IMO, proving the CO2 bit-transparent in that scenario doesn't help us because our real concern is how it performs in the field with a different combination of gear.

[hexyjones]

Isn't it true there is a great deal of variation in the implementation of SPDIF spec?


And - I understand the comparison method..but...

Is there anything one can look for in an existing recording to detect any problems?

Wouldnt some software complain if there were samples missing?

[Brian Skalinder]

Isn't it true there is a great deal of variation in the implementation of SPDIF spec?

As I understand it, yes.

Is there anything one can look for in an existing recording to detect any problems?

If you drill into the wavform closely enough - and I meany *really* close - you may be able to see misplaced or dropped samples.  Some WAV editors may have a way of doing this automatically, but [1] they may not be precise, and [2] I'm not certain if they actually do.

Wouldnt some software complain if there were samples missing?

Nope.

[SparkE!]

Brian, my hope is that by understanding the design limitations of the CO2, we can more easily predict when its use with some particular type of equipment will work and when it will not.  Knowing those things will not reduce the imporance of testing for bit accuracy, but it can help us to avoid wasting time testing combinations that have no chance of working.

For what it's worth, I like my ODL-276 and it has worked well with every piece of gear to which it has been connected.  I don't see any reason that I'll ever be in the market for a CO2.  On the other hand, I don't necessarily look down my nose at recordings that were made with a CO2 in the lineage, but it does make me wary of the source.  Normally I would prefer a source whose lineage did not involve a CO2.  (Yes, I too am guilty of stereotyping the CO2, but I'm trying to be more open minded. )