Become a Site Supporter and Never see Ads again!

Author Topic: co2>jb3  (Read 11524 times)

0 Members and 1 Guest are viewing this topic.

hexyjones

  • Guest
  • Trade Count: (0)
Re: co2>jb3
« Reply #15 on: February 18, 2005, 12:31:09 PM »
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?

Offline SparkE!

  • Trade Count: (0)
  • Taperssection Member
  • ***
  • Posts: 773
Re: co2>jb3
« Reply #16 on: February 18, 2005, 03:59:25 PM »
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.
How'm I supposed to read your lips when you're talkin' out your ass? - Lern Tilton

Ignorance in audio is exceeded only by our collective willingness to embrace and foster it. -  Srajan Ebaen

Offline bagtagsell

  • Trade Count: (0)
  • Taperssection All-Star
  • ****
  • Posts: 1221
  • Gender: Male
  • Man is condemned to be free- Sartre
Re: co2>jb3
« Reply #17 on: February 18, 2005, 04:41:14 PM »
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
MG200/210>m148>v3>MT2496
                       
*aspiring gear slut of the month year*
"I am the gear slut goo goo g’joob g’goo goo g’joob"

hexyjones

  • Guest
  • Trade Count: (0)
Re: co2>jb3
« Reply #18 on: February 18, 2005, 05:03:14 PM »
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

  • Guest
  • Trade Count: (0)
Re: co2>jb3
« Reply #19 on: February 18, 2005, 05:06:48 PM »
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

    Offline F.O.Bean

    • Team Schoeps Tapir that
    • Trade Count: (126)
    • Needs to get out more...
    • *****
    • Posts: 40690
    • Gender: Male
    • Taperus Maximus
      • MediaFire Recordings
    Re: co2>jb3
    « Reply #20 on: February 18, 2005, 05:38:11 PM »
    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
    Schoeps MK 4V & MK 41V ->
    Schoeps 250|0 KCY's (x2) ->
    Naiant +60v|Low Noise PFA's (x2) ->
    DarkTrain Right Angle Stubby XLR's (x3) ->
    Sound Devices MixPre-6 & MixPre-3

    http://www.archive.org/bookmarks/diskobean
    http://www.archive.org/bookmarks/Bean420
    http://bt.etree.org/mytorrents.php
    http://www.mediafire.com/folder/j9eu80jpuaubz/Recordings

    Offline SparkE!

    • Trade Count: (0)
    • Taperssection Member
    • ***
    • Posts: 773
    Re: co2>jb3
    « Reply #21 on: February 18, 2005, 10:27:05 PM »
    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
    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.
    How'm I supposed to read your lips when you're talkin' out your ass? - Lern Tilton

    Ignorance in audio is exceeded only by our collective willingness to embrace and foster it. -  Srajan Ebaen

    Offline Brian

    • Trade Count: (2)
    • Needs to get out more...
    • Posts: 9392
    • Gender: Male
    Re: co2>jb3
    « Reply #22 on: February 19, 2005, 01:02:39 AM »
    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.........



    +T for the informative posts on this subject SparkE!

    -Brian

    PS:  just messin' with ya bean ;)

    Offline F.O.Bean

    • Team Schoeps Tapir that
    • Trade Count: (126)
    • Needs to get out more...
    • *****
    • Posts: 40690
    • Gender: Male
    • Taperus Maximus
      • MediaFire Recordings
    Re: co2>jb3
    « Reply #23 on: February 19, 2005, 03:05:35 AM »
    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
    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 ;D 8)
    Schoeps MK 4V & MK 41V ->
    Schoeps 250|0 KCY's (x2) ->
    Naiant +60v|Low Noise PFA's (x2) ->
    DarkTrain Right Angle Stubby XLR's (x3) ->
    Sound Devices MixPre-6 & MixPre-3

    http://www.archive.org/bookmarks/diskobean
    http://www.archive.org/bookmarks/Bean420
    http://bt.etree.org/mytorrents.php
    http://www.mediafire.com/folder/j9eu80jpuaubz/Recordings

    hexyjones

    • Guest
    • Trade Count: (0)
    Re: co2>jb3
    « Reply #24 on: February 19, 2005, 03:45:59 AM »
    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!)

    Offline F.O.Bean

    • Team Schoeps Tapir that
    • Trade Count: (126)
    • Needs to get out more...
    • *****
    • Posts: 40690
    • Gender: Male
    • Taperus Maximus
      • MediaFire Recordings
    Re: co2>jb3
    « Reply #25 on: February 19, 2005, 04:01:26 AM »
    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 ;)
    Schoeps MK 4V & MK 41V ->
    Schoeps 250|0 KCY's (x2) ->
    Naiant +60v|Low Noise PFA's (x2) ->
    DarkTrain Right Angle Stubby XLR's (x3) ->
    Sound Devices MixPre-6 & MixPre-3

    http://www.archive.org/bookmarks/diskobean
    http://www.archive.org/bookmarks/Bean420
    http://bt.etree.org/mytorrents.php
    http://www.mediafire.com/folder/j9eu80jpuaubz/Recordings

    Offline Brian Skalinder

    • Complaint Dept.
    • Trade Count: (28)
    • Needs to get out more...
    • *****
    • Posts: 18868
    • Gender: Male
    Re: co2>jb3
    « Reply #26 on: February 19, 2005, 07:49:14 AM »
    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? 
    Milab VM-44 Links > Fostex FR-2LE or
    Naiant IPA (tinybox format) >
    Roland R-05

    Offline SparkE!

    • Trade Count: (0)
    • Taperssection Member
    • ***
    • Posts: 773
    Re: co2>jb3
    « Reply #27 on: February 19, 2005, 10:34:54 AM »
    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?
    How'm I supposed to read your lips when you're talkin' out your ass? - Lern Tilton

    Ignorance in audio is exceeded only by our collective willingness to embrace and foster it. -  Srajan Ebaen

    hexyjones

    • Guest
    • Trade Count: (0)
    Re: co2>jb3
    « Reply #28 on: February 19, 2005, 11:06:25 AM »
    Not sure if it helps -  but here's one inside shot...

    Offline SparkE!

    • Trade Count: (0)
    • Taperssection Member
    • ***
    • Posts: 773
    Re: co2>jb3
    « Reply #29 on: February 19, 2005, 11:09:15 AM »
    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.
    How'm I supposed to read your lips when you're talkin' out your ass? - Lern Tilton

    Ignorance in audio is exceeded only by our collective willingness to embrace and foster it. -  Srajan Ebaen

     

    RSS | Mobile
    Page created in 0.129 seconds with 39 queries.
    © 2002-2024 Taperssection.com
    Powered by SMF