Taperssection.com
Gear / Technical Help => Post-Processing, Computer / Streaming / Internet Devices & Related Activity => Topic started by: taylorc on February 17, 2004, 01:09:30 AM
-
Issue: Cannot get a pure/exact digital transfer
Comparing:
Downloaded shn> wav copy of show A (100% accurate)
-to-
DAT> M-Audio Audiophile 2496> PC copy of show A
Results:
1. Transferred copy distorts at higher volumes before the dl'ed original version does
2. The physical appearance of the transferred copy's soundwaves' graphics lose their texture before the original copy does
Using: Win XP, DA-20, 75ohm coax, Latest Driver, Sound Forge7.0, Samplitude6.0, EAC, CDWav
Attempted solutions: Mulitple PCI slots, unsuccessful communication with and return to M-Audio, tweaking of settings, etc.
Any input? If I need to provide more information, please ask...
-
Is SF set to the same sample rate as the DAT that you are transferring?
-
I use a similar set-up, and i think you may be right. Try checking for inadvertent downsampling (was the original in 20-bit, like my A/D throws).
UJ
-
are you sure that the person who transferred the copy you downloaded didnt do any mastering?
this is always possible.
I use the Audiophile 2496 and all of my digital transfers come out clean and pure everytime
-
luvean,
what software do you use to capture the signal? also, how do you test that your copies are bit-perfect? (you didn't actually mention that, so I'm just taking a shot.)
UJ
-
I use Soundforge 6.
the Audiophile 2496 is a KNOWN bit-perfect card with a DC offset of 0
-
OK, but for some reason i thought that recording through, say, CDWav was not bit-perfect. Is it necessary to use something like Soundforge? If not, OK. If so, what is it about SF that makes it better at sound capture than CDWav?
Also, how is it KNOWN to be bit-perfect? Any documentation or the like? Or is that just something you heard and believed?
Thanks,
UJ
-
I get the same results with any transfer. Any high frequencies have a "lossy" effect.
My specific comparison has been done with Phish 4.5.98 641>Sax>P1. I have it in numerous versions: PCP CD-R, DAT, shn (that I've used to compare).
All signs indicate that the card is good and installed/setup properly. DAT's play fine through the DA-20 I use for transfers. Just wondering if something on my PC is conflicting with the card?...
-
I dont see how recording through CDWave would not be bit-perfect.
as for why I use SF, personal preference...I use CDWave for tracking.
there have been numerous tests over the years showing that the Audiophile 2496 is bit perfect in the 16bit realm...24bit is somewhat a different story.
-
I dont see how recording through CDWave would not be bit-perfect.
as for why I use SF, personal preference...I use CDWave for tracking.
But you don't know the technical details of why it is bit-perfect?
there have been numerous tests over the years showing that the Audiophile 2496 is bit perfect in the 16bit realm...24bit is somewhat a different story.
Can you link to these tests, or tell me who performed them, or anything like that? At a sample rate of 44.1 or 48 thousand samples (16 bits each? 20?) per second, it's hard for me to believe that the transfer is perfect on the fly, with little time for error correction, without some kind of evidence.
Case in point, sometimes it takes longer than real time to overcome errors in EAC, for those specific bits. An audio transfer is one direction only and does not have the benefit of reading the same sample 8 or 16 or 32 times to determine what it might be.
Thanks for the discussion,
UJ
-
well, honestly I dont have the time to redig through old DAT Heads digests(I remember seeing tests on the Audiophile 2496 back in 2000/2001 before I originally purchased mine)
as for CDWave, no, I'm not a programmer, so I dont know the internal workings/functions it is using. that said, I would seriously doubt that CDWave is NOT bit perfect based on the personal and community recomendations to use it(and knowing how anal these people are with regards to being bit-perfect and such...)
you are confusing dat> hd transfers with eac....extracting data from a cd is inherently risky and prone to errors, that is why EAC has the error corrections.
as for transfering dat> hd there is much less of a chance of errors being introduced. the reason why some cards are not bit-perfect is that they resample on the fly regardless of incoming signal. this is bad...the Audiophile 2496 does NOT do this UNLESS you have the cards mixer controls set up incorrectly.
when transferring dat> hd you need to make sure the sample rate is matched in 3 places: the dat, the transfer card and the recording software.
from above you posted that your ADC outputs 20bit...which ADC are you using? if recording to DAT through s/pdif the ADC should only be outputting 16bits(it may process internally at 20bits, but it then either dithers or use some other noise-shaping algorithm to output 16bits)
for your transfers have you checked to see if your PC environment is creating a DC offset? this could help explain why the transferred audio different visually and sonically from the dat.
-
OK, well, I can go look at DAT-heads myself now that you have mentioned it.
As for CDWav, it is used "by the community" as an accepted way to trim or track out .wavs because it always splits on sector boundaries. I have not seen too many people suggest that it be used as a recorder, just that it has that capability if you don't have SF or Wavelab or whatever.
Why is there less chance of errors during a transfer, and how does it correct if there are errors? How does it even know?
I use a Gram-Patton (sp?) ADC-20. I am relatively new to that, so it may very well only process 20 bits internally, but i'd have to check instead of assuming that i know something that i really do not.
How do I check for a DC offset?
I'm not trying to be argumentative. It just doesn't seem that there is much hard evidence so far, although you do seem to be quite experienced with your own set-up.
I do appreciate the tip on the sample rates, although that is a macro-type problem that usually resuls in severely distorted, unnatural sounding audio, rather than the second order effects of some peaks clipping early.
One more thing, how would the settings be set up wrong vs right on the card for resampling on the fly? Specifically? Just the internal vs external clock? if that is the case, then CDWav isn't bit perfect at all, as it will not record with an external clock signal.
UJ
-
with dat> hd transfers, if you notice a error in the waveform that isnt on the dat, you simply retransfer..the error could be anything from a dropped sample to a missplaced sample.
not sure how to check for DC offsets in anything but SoundForge. in SF, in the record dialouge there is a checkbox for checking DC Offset and a button underneath to correct any DC offset it finds.
DC Offset sounds more likely to be the culprit of the problems originally described at the top of this thread
-
OK, thanks. One last thing...
If there IS an error in the waveform, doesn;t that mean that the transfer was not bit-perfect, by definition? It would be pretty inconvenient and quite inexact if the only way to check the "bit-perfectness" was to listen to the DAT and then look at/listen to the waveform.
Can anyone else jump in here and add some knowledge? I think we have hit the rail on actual knowledge of the subject and are cruising into pure speculation.
UJ
-
fyi, most errors are caused by the tape itself and the s/pdif cable between the dat and the card
-
Generally speaking, when we refer to bit-perfect soundcards, we mean the soundcard is capable of being bit-perfect within the greater chain of gear used for transfers. All links in the chain must perform bit-perfectly to achieve a bit-perfect transfer. Failures may occur in any number of links in the chain:
- damaged/faulty tape
- misaligned or dirty DAT playback heads
- digital connector/cable problems
- soundcard hardware issues
- soundcard driver configuration
- recording software configuration
- operating system configuration
- RAM usage
- virtual memory configuration
- hard drive health (e.g. fragmentation) and/or spin rate
- CPU health (e.g. overheating) and usage
There are probably other links in the chain, but you get the idea. Problems in any one or more of these areas may contribute to a bit-imperfect transfer, and only when all these links in the chain are operating properly do we achieve bit-perfect transfers. And as Luvean suggested, most artifacts or bit-imperfection issues are often related to a link in the chain other than the soundcard.
If we all really want to ensure our transfers are bit-perfect, we should transfer twice and compare the resulting WAVs (the odds of the same sample being misplaced/dropped in exactly the same way and exactly the same place on both transfers is astronomically high). Of course, transferring every DAT twice is a major PITA.
Since it is a reality that not everyone has the time, knowledge, or skill to perform every transfer twice and compare, or even to test a single time the exact combination of links which make up their particular transfer chain, we all invariably rely on testing performed by others - fellow tapers, manufacturer support and tech reps, even retailers. Hence, Luvean's mention of the previous tests posted to DAT-Heads.
To address the original point of the thread, we need a lot more information:
- How was SHN > WAV performed?
- Did the operation complete without errors?
- How were the WAVs transferred to DAT? (i.e. what were the exact links in the chain, per above*)
- How was the DAT transferred back to PC? (i.e. what were the exact links in the chain, per above*)
* Your original post lists the following:
Using: Win XP, DA-20, 75ohm coax, Latest Driver, Sound Forge7.0, Samplitude6.0, EAC, CDWav
[/list]But more detailed information would be useful. For example, for what purposes was EAC used? Did you use SF7 or Samplitude 6 for conversion? When and how was CDWave used? How is your WinXP machine configured? When was the last time the heads on the DA-20 were cleaned and/or aligned? Specifically what kind of coax cable? Latest Driver = ...what version? How was your soundcard configured, etc.?
So, yeah...that's a lot of information to provide. My initial reaction is that the issue is not related to bit-perfectness, but more likely a soundcard configuration issue during WAV > DAT or DAT > WAV transfer.
Some additional questions:
- What do you mean when you say the copy distorts at higher volumes before the downloaded original does?
- How are the copy and master each being played back?
- I'm not sure what you mean by the copy's wavform "loses texture" before the original - please explain?
-
Thanks, B.
+T if i could, and if it mattered.
Peace to ya,
UJ
-
Hey UJ --
You still looking for a resolution on this? If so, gotta have answers to these questions for starters:
Some additional questions:
* What do you mean when you say the copy distorts at higher volumes before the downloaded original does?
* How are the copy and master each being played back - what's the playback chain(s)?
* I'm not sure what you mean by the copy's wavform "loses texture" before the original - please explain?
-
Not my thread... just jumped in on the discussion, as I have questions about the bit-perfectness of CDWav.
Thanks, tho.
-
Not my thread... just jumped in on the discussion, as I have questions about the bit-perfectness of CDWav.
Oops, my mistake. Phoam - any resolution on this yet?
-
* What do you mean when you say the copy distorts at higher volumes before the downloaded original does?
* How are the copy and master each being played back - what's the playback chain(s)?
* I'm not sure what you mean by the copy's wavform "loses texture" before the original - please explain?
Distorts at higher volumes...as in it losing its resolution. While the shn>wav copy continues to play without any problems, the transferred copy is unable to "keep it together". It's still quite audible...just not 100% pure.
Both are played back through the same stereo receiver/speakers. DAT> Receiver / AP2496> Receiver.
Texture...referring to viewing the soundwaves in Sound Forge. Placing the two copies side-by-side, as I focus in, the transferred copy becomes "rigid" before the shn>wav copy.
I can't detect any audible problems with my DAT dack on playback, but it does get high error readings and hasn't had a manual cleaning in a good while.