Digital to Digital Transferes (accurate-NOT)
Gabe M. Wiener
tojo nixon <tojo_...@mindlink.bc.ca> wrote:
>Anyone critically LISTENING to their digital transferes knows that you can
>never get out what you put in.
Well, I do a great deal of critical listening (that's what people pay me for)
and I find that with digital transfers, you can often get out what you put
in, if you make the transfer correctly.
>If you do a digital transfere from one dat machine to another and play back the copy
>(analog out) you will NEVER hear the sound to be identical to the original.
This is incorrect. If your DAT reproduces the bitstream without error (easily
verifiable by doing a bit-compare in a workstation) and if your DAC properly
attenuates jitter, the two tapes will sound identical.
>the case). The copys have less depth and more grain ALWAYS but at slightly different
>frequencies depending on the recorder used.
Once again, this will only be the case if your recorder is either dropping
bits or is highly jitter-intolerant.
> This is ALWAYS the case, irrelevant of the chain used.
Care to defend that statement? I'd be willing to wager any amount of money
that I could assemble a transfer chain between two DAT machines, make a copy
of a tape, and in a controlled listening test, you would not be able to
identify which was which.
>I have tryed the original recording machine to another of the same
>kind and back to the original machine (to eliminate jitter),
Why would this eliminate jitter? This might even amplify jitter, because
there is good reason to believe that if a machine is jitter-prone in one
area of the spectrum, it is likely to be so both during transmission and
reception.
Have you read any of the salient papers on jitter, re-clocking, etc? If
so, it doesn't seem like you heeded the advice presented therein.
What sorts of jitter attenuation techniques did you employ?
>The original DAT tape will sound different on every machine it is played on (with
>the same depth problem) except on the original recorder. The same model was used
>with worse results.
Given that all DAT machines have lousy internal DACs compared to the state-
of-the-art in what's out there, it is not surprising that tapes played back
on different machines sound different.
If the signals from the DAT machines are fed to a single DAC in the digital
domain, there will only be noticeable sonic differences if one deck has
better ability to track a bad tape, or if one deck is jittery and the DAC
is jitter-intolerant.
What tests did you run to determine which, if either, of these conditions
exists?
>Transferes from DAT to and from Pro Tools and Sonic Solutions had the same problems
>but listening from these systems only (and not taking it back to DAT) sounded like
>the player being used, and the original recorder with the original DAT sounded best.
Thanks for telling us the source of your word-sync in such a test.
>Conclusions?
My conclusions are, either:
Your testing methodology is woefully inadequate, or
Your tests are fine and your reporting is highly unscientific.
Digital transfers can indeed sound different, but the phenomena that brings
that about is reasonably well understood.
--
Gabe Wiener Dir., Quintessential Sound, Inc. |"I am terrified at the thought
Recording-Mastering-Restoration (212)586-4200 | that so much hideous and bad
PGM Early Music Recordings ---> (800)997-1750 | music may be put on records
ga...@panix.com http://www.panix.com/~gabe | forever." --Sir Arthur Sullivan
tojo nixon
have come to certain realizations:
1)
If you do a digital transfere from one dat machine to another and play back the copy
(analog out) you will NEVER hear the sound to be identical to the original. Some
copys sound better then others (usually the more expensive machines, but not always
the case). The copys have less depth and more grain ALWAYS but at slightly different
frequencies depending on the recorder used. This is ALWAYS the case, irrelevant of
the chain used. I have tryed the original recording machine to another of the same
kind and back to the original machine (to eliminate jitter), and every other
permiutation we could think of using all manufacturers and models we could find
(Sony, Panasonic, Tascam, being the most popular brands). We tryed using sync clocks
with no remedy. The better the recording (clearer) the easier the difference is
heard
2)
The original DAT tape will sound different on every machine it is played on (with
the same depth problem) except on the original recorder. The same model was used
with worse results.
3)
Transferes from DAT to and from Pro Tools and Sonic Solutions had the same problems
but listening from these systems only (and not taking it back to DAT) sounded like
the player being used, and the original recorder with the original DAT sounded best.
4)
Apparantly (I have not heard this myself but the source is very reputable) if you
make a CD out of Sonic, all the copys from all the different machines will sound
identical. I have made a CD using an original DAT on an original recorder and
compared it to an original DAT on the original recorder and they are ALMOST
identical. The CD had an ever so slight less depth of field but was the best I have
heard bar none. I have not yet tested to see if the manufacturing plant could
reproduce these well.
Conclusions?
If you do digital transferes be careful and critical. Just because you are satisfied
with your original and your guard is down with these "identical digital transferes"
dont be fooled. If your final goal from the transferes is a CD you are lucky(er) but
if you go analog out you are not (ie in a mix situation).
If you use digital and are happy with the sound you get with your great
a/d converters and analog it out with no copys you should be pleased with the
results (they should be identical).
If you have had better luck with transferes and disagree, or agree totaly, I hope
to see your postings.
tojo
tojo nixon
primarily educate myself
and then anyone else interested in the matter discussed. Any relevant comments are
much
respected by me. Thank you for showing an interest.
I write
>If you do a digital transfere from one dat machine to another and play back the copy
>(analog out) you will NEVER hear the sound to be identical to the original.
they comment
This is incorrect. If your DAT reproduces the bitstream without error (easily
verifiable by doing a bit-compare in a workstation) and if your DAC properly
attenuates jitter, the two tapes will sound identical.
i respopnd
PLEASE NAME ME THE DAT PLAYERS. I WILL NAME SEVERAL BRANDS AND MODEL
NUMBERS THAT DO NOT YIELD IDENTICAL SOUNDING DAT TAPE COPYS WHEN
DIGITALLY TRANSFERRING BETWEEN TWO DECKS. PANASONIC 3500, 3700,4100
(unfortyunately my new recorder), TASCAM DA30MKII, SONY 2300, 2700, 7030. AND ALSO
THE THE STUDER DYAXIS AND SONY PCM-1630( (not from my experience but this is from
May 1991 (sooo long ago ) MIX magazine, pg 85, "The Question of Digital Transferes"
by Bob
Hodas (isn't the 1630 what your CD manufacturer got from you last year??!!). I have
never a/b'd
a 1630 and I have never used a Dyaxis system at all) the article names some big
NAMES in the
industry)
If I left out any DAT players (of course I did) please mention them and we will see
how popular
they are (ie:only VERY FEW people use an OTARI DAT player, despite of how excellent
or bad
they are, so I didn't test them (or know if they exist) as they were not redily
available to me in my
sphere). If anyone has a DAT player that DOES DO PERFECT DIGITAL TRANSFERES, LET US
ALL KNOW SO WE CAN TRY IT. Unfortunately, when I listen (and not look at a
computer) they
don't SOUND the same to my ears and to any other listeners eares (the listeners
sometimes only
after some pointing out like saying "listen to just the bass guitar and its
placement in the mix
instead of just listening to the overall mix eq") that are present. Eventually ALL
listeners can hear
the difference and EVERYONE agrees to the better sounding DAT. The reasons are
always the
same, "better depth" and "less grain or distortion".
I write
> This is ALWAYS the case, irrelevant of the chain used.
they comment
Care to defend that statement? I'd be willing to wager any amount of money
that I could assemble a transfer chain between two DAT machines, make a copy
of a tape, and in a controlled listening test, you would not be able to
identify which was which.
I respond:
BETWEEN TWO DAT MACHINES IF YOU HOOK UP TWO STORE BOUGHT 3-prong AES
CABLES, OR USE THE CO-AXIAL STORE BOUGHT CABLES (usually shipped with your new
recorder) YOU WILL HEAR THE DIFFERENCE (as will everyone else present). IF THERE IS
A
BLACK BOX THAT NEEDS TO BE IN THE SIGNAL PATH LET ME KNOW SO I CAN BUY IT. IN
THE MANUALS AND ACCORDING TO SALESMEN NOTHING EXTRA IS NEEDED (and I have
never used anything else! except for external clocks) FOR PERFECT DIGITAL TRANSFERES
BETWEEN TWO MACHINES. AS A CONTROLLED LISTENING TEST I WOULD SAY GOOD
SPEAKERS WOULD BE NEEDED (ie: Tannoys or Genelec, etc.) AND THE LISTENERS
WOULD NOT KNOW WHICH THE LISTENED TO CHOICE WAS (copy or not). THEY WOULD
ONLY CHOOSE BETTER OR WORSE AND GIVE THEIR REASONS WHY (LISTENING TO
IDENTICAL SEGMENTS OF MUSIC ABOUT 30 SECONDS OR MORE IN DURATION IS
REQUIRED, LISTENING FOR A FEW SECONDS AND SWITCHING IT IS HARD TO NOTICE
THE DIFFERENCE AS FREQUENCY DIFFERENCES ARE HEARD (which there is none of -
digital is quite flat from 20Hz to 20kHz) INSTEAD OF "DEPTH" DIFFERENCES WHICH ARE
IMPORTANT IN DIGITAL TRANSFERES.
I write
>I have tryed the original recording machine to another of the same
>kind and back to the original machine (to eliminate jitter),
they comment:
Why would this eliminate jitter? This might even amplify jitter, because
there is good reason to believe that if a machine is jitter-prone in one
area of the spectrum, it is likely to be so both during transmission and
reception.
I reply:
I am first to admit that I cannot technically explain the differences. I use only
subjective terms as
"depth" and "grain" while you use facts like "bit for bit accurate" which seem to
have more
weight. Experts explained (and I tryed to understand) that the phenomenon that I
noticed was
due to JITTER and not to accuracy of transferes. When I thought that jitter might be
reduced in
this way I was thinking this: 1) the first machine has jitter but the analog output
sounds like you
would want it to so it is not a problem for you, or you accept the sound and say it
is the best you
got 2) after digitally transfering to a second machine, the second machine would
completely re-
read the digital signal during analog and digital playback with its own clock
creating
unpredictable (or unknown) jitter, which is totally independant of the first machine
(if it is "bit for
bit accurate and no errors are caused") and dependant on the second machines clock.
3)the
final source machine (the original machine) would read the digital stream and "bit
accurately"
copy the info to tape. Upon accepting the digital info, during playback jitter would
be somewhat
the same as the original recording so you could compare with the original (ie the
same clock,
and totally independant of the previouse machines clocks). If I am misinformed
(highly probable)
you will surely let me know. Regardless, it didn't SOUND the same despite the reason
why AND
EVERYBODY SAYS THAT IT SHOULD SOUND THE SAME, AND WHO CARES ABOUT BITS
ANYWAYS, SOUND IS IMPORTANT!!!! NOT BITS!
they write
Have you read any of the salient papers on jitter, re-clocking, etc? If
so, it doesn't seem like you heeded the advice presented therein.
What sorts of jitter attenuation techniques did you employ?
I write
SORRY. THE ONLY TECHNIQUES I USED WAS USING GOOD CABLE AND CONNECTING
TOGETHER TWO MACHINES OUT OF THEIR DIGITAL PORTS (how naive??) I USED MANY
DIFFERENT CABLES AND MANY DIFFERENT MACHINES. SOMETIMES I USED EXTERNAL
CLOCKS (from an unused DAT machine connected to all inputs of all machines used in
the
digital transfere) SO THAT ALL MACHINES WERE SYNCHRONIZED. ONLY FEW MACHINES
ALLOW THIS THOUGH. IF I DIDN't DO ANYTHING RIGHT LET ME KNOW, AS NOBODY ELSE
HAS! (this includes customer service, salesmen, and ALL ENGINEERS at the studios I
went to)
AND THE MACHINES MANUALS CERTAINLY DON'T MENTION.
They say
Given that all DAT machines have lousy internal DACs compared to the state-
of-the-art in what's out there, it is not surprising that tapes played back
on different machines sound different.
If the signals from the DAT machines are fed to a single DAC in the digital
domain, there will only be noticeable sonic differences if one deck has
better ability to track a bad tape, or if one deck is jittery and the DAC
is jitter-intolerant.
What tests did you run to determine which, if either, of these conditions
exists?
I respond
I played all tapes for listening out of ONE deck per test. This one deck was
sometimes the
original deck, an identical deck, or a totaly unrelated deck. This used ONE d/a
converter for all
the tapes. I also sometimes used playback through Sonic Solutions and PRO TOOLS
(when
testing these systems) of the different versions of copys. No separate d/a
converters were
available to me (a/d are much more prevelant where I am from and make a big
differance) so I
only used DAT recorders and DAW's d/a converters. I NEVER KNEW d/a CONVERTERS WERE
IMPORTANT IN DIGITAL TRANSFERES. MY POINT IS THAT WHEN I RECORD ON MY
MACHINE, AND THEN MAKE A COPY, THE COPY WILL NEVER SOUND THE SAME ON MY
MACHINE AGAIN COMPARED TO THE ORIGINAL. This is most important as we are talking
about audio, not bits. This DIFFERENCE is relevant because if you are using your DAW
for
comping (say combining many vocal takes) and then using its analog outs during a mix
(to a
state of the art analog console) and you take the final mix down to 2-track. Most
people don't
have access to a digital console. Also some people use "a-dats" as cheap accurate
storage for
their digital data when their hard drive space is low, afterall it is just digital
transfer.
I say
>Transferes from DAT to and from Pro Tools and Sonic Solutions had the same problems
>but listening from these systems only (and not taking it back to DAT) sounded like
>the player being used, and the original recorder with the original DAT sounded best.
they say
Thanks for telling us the source of your word-sync in such a test.
I say
I NEVER KNEW THAT I NEEDED AN EXTERNAL WORD SYNC TO MAKE THE PERFECT
TRANSFERES. all THE ENGINEERES AT THE DIFFERENT STUDIOS NEVER HEARD OF
THIS. WE ALL THOUGHT THIS: 1)hook up the source DAT to the DAW 2)the DAW
automatically acts as a slave in the transfere, the DAT machine as the source clock,
(if digital
protocoll is the same, many of the time you don't have a choice except for in the
DAW.) Usually you just connect the
correct ports and they work
If we are incorrect, I can safely say that MOST PEOPLE think my method is the
correct method.
YOU as EXPERTS should inform us or the equipment MANUFACTURERS should. Everyone so
far has just said "hook up the digital out of one device to the digital in of
another, making sure
you use the correct co-ax or AES cable" Let us know if we are wrong!!!!
ODDLY ENOUGH, I have tryed using an external clock to all the machines. I used the
"digital
audio data sync" but not the "word-sync". I got no better results.
IS THERE SOME LITERATURE ON DIGITAL CONNECTIVITY (published books I can buy). I
find hardly any and use my manuals as referance.
AS I stated previously, I have tryed to acieve a perfect digital transfer for over
five years now and
have never done it nor has it been done for me by ANYONE. A very reputable mastering
house
in LA (which has done many #1 hits) as a regular procedure analog outs DAT tapes and
puts
them through eq/compression and then onto a 1630. So much for digital transferes,
but the mastering house does indeed yield excellent results.
COMMENTS??????
I await being proven wrong and hope I am mislead, and identical digital transferes
are a reality.
PS: Just in case, these differences that I am talking about are NOT IN FREQUENCY (ie
no high
end loss or bass loss) and you will not hear them there (as you would in analog).
The differences
are in depth (ambience) and imaging (ie: is the vocal placed deep in the center or
is it smeared
in the center? Placement is important.)
tojo nixon
Scott Dorsey
>
>they comment
>This is incorrect. If your DAT reproduces the bitstream without error (easily
>verifiable by doing a bit-compare in a workstation) and if your DAC properly
>attenuates jitter, the two tapes will sound identical.
>
>i respopnd
>PLEASE NAME ME THE DAT PLAYERS. I WILL NAME SEVERAL BRANDS AND MODEL
>NUMBERS THAT DO NOT YIELD IDENTICAL SOUNDING DAT TAPE COPYS WHEN
>DIGITALLY TRANSFERRING BETWEEN TWO DECKS. PANASONIC 3500, 3700,4100
>(unfortyunately my new recorder), TASCAM DA30MKII, SONY 2300, 2700, 7030. AND ALSO
>THE THE STUDER DYAXIS AND SONY PCM-1630( (not from my experience but this is from
>May 1991 (sooo long ago ) MIX magazine, pg 85, "The Question of Digital Transferes"
>by Bob
>Hodas (isn't the 1630 what your CD manufacturer got from you last year??!!). I have
>never a/b'd
>a 1630 and I have never used a Dyaxis system at all) the article names some big
>NAMES in the
>industry)
None of this stuff really is known for having great converters inside. I can
attest to the fact that the 1630 has in fact what are probably the worst ADCs
that I have ever heard in my life, bar none.
What is happening here is that you are hearing distortion which is the
result of jitter, because you aren't using an outboard converter which
reclocks the data. On top of this, unless you are very careful about
using the same equipment for playback, you may even be noticing the very
significant differences in converters between machines.
Run out and buy the Audio Alchemy DAC-In-The-Box. I think it lists for
$199. It's not a world-class DAC, but I think you will find that a lot
of the differences between different generation dubs will disappear
with a decent outboard DAC of any sort.
I don't doubt that you are hearing something, but what you are hearing
here is the result of the equipment and not the process itself. An
outboard DAC which reclocks the data will eliminate these problems.
> If I left out any DAT players (of course I did) please mention them and we will see
>how popular
>they are (ie:only VERY FEW people use an OTARI DAT player, despite of how excellent
>or bad
>they are, so I didn't test them (or know if they exist) as they were not redily
>available to me in my
>sphere). If anyone has a DAT player that DOES DO PERFECT DIGITAL TRANSFERES, LET US
>ALL KNOW SO WE CAN TRY IT. Unfortunately, when I listen (and not look at a
>computer) they
>don't SOUND the same to my ears and to any other listeners eares (the listeners
>sometimes only
>after some pointing out like saying "listen to just the bass guitar and its
>placement in the mix
>instead of just listening to the overall mix eq") that are present. Eventually ALL
>listeners can hear
>the difference and EVERYONE agrees to the better sounding DAT. The reasons are
>always the
>same, "better depth" and "less grain or distortion".
The problem isn't in the transfer, the problem is in the playback. What is
happening is that your dupe tape has slightly different bit timing than the
original. This is okay, it's part of the reason we can get away with so much
in the digital process, and it's something a good playback system will
correct for so you won't have to worry.
With a good DAC, you should be able to make seamless transfers with _any_
DAT deck. With the DACs that are built into most DAT decks, you may well
notice some problem. So use an outboard converter and stop sweating this
kind of problem.
>I write
>> This is ALWAYS the case, irrelevant of the chain used.
>
>they comment
>Care to defend that statement? I'd be willing to wager any amount of money
>that I could assemble a transfer chain between two DAT machines, make a copy
>of a tape, and in a controlled listening test, you would not be able to
>identify which was which.
>
>I respond:
>BETWEEN TWO DAT MACHINES IF YOU HOOK UP TWO STORE BOUGHT 3-prong AES
>CABLES, OR USE THE CO-AXIAL STORE BOUGHT CABLES (usually shipped with your new
>recorder) YOU WILL HEAR THE DIFFERENCE (as will everyone else present). IF THERE IS
>A
>BLACK BOX THAT NEEDS TO BE IN THE SIGNAL PATH LET ME KNOW SO I CAN BUY IT. IN
>THE MANUALS AND ACCORDING TO SALESMEN NOTHING EXTRA IS NEEDED (and I have
>never used anything else! except for external clocks) FOR PERFECT DIGITAL TRANSFERES
>BETWEEN TWO MACHINES. AS A CONTROLLED LISTENING TEST I WOULD SAY GOOD
>SPEAKERS WOULD BE NEEDED (ie: Tannoys or Genelec, etc.) AND THE LISTENERS
>WOULD NOT KNOW WHICH THE LISTENED TO CHOICE WAS (copy or not). THEY WOULD
>ONLY CHOOSE BETTER OR WORSE AND GIVE THEIR REASONS WHY (LISTENING TO
>IDENTICAL SEGMENTS OF MUSIC ABOUT 30 SECONDS OR MORE IN DURATION IS
>REQUIRED, LISTENING FOR A FEW SECONDS AND SWITCHING IT IS HARD TO NOTICE
>THE DIFFERENCE AS FREQUENCY DIFFERENCES ARE HEARD (which there is none of -
>digital is quite flat from 20Hz to 20kHz) INSTEAD OF "DEPTH" DIFFERENCES WHICH ARE
>IMPORTANT IN DIGITAL TRANSFERES.
You're shouting again. Please stop that. In any case, the fact that you
can hear differences between the cables immediately indicates that something
is wrong. The digital systems are _designed_ to keep you from hearing this
kind of effect, and if you _can_ hear it than you have a problem. Yes, I do
this kind of controlled listening test on a regular basis in order to test
out other unrelated things and have never had problems with my listening
panel hearing differences between identical tapes. Then again, I am also
using an outboard converter and using the same converters for multiple
sources, distributing S-PDIF through a video patch bay.
What is happening is that the device is possibly reclocking everything at
every step, and changing the jitter spectrum at each step, so this isn't
going to eliminate jitter at all, it will just change it, and it won't
do so in any consistent manner. The only time that jitter should matter is
in the final playback where you are going into a DAC... and if the DAC
doesn't reclock the data, the jitter (which basically means phase error)
on the digital signal will cause the effects you are describing. Once again,
the cheap and easy solution is to get a DAC that reclocks.
>they write
>Have you read any of the salient papers on jitter, re-clocking, etc? If
>so, it doesn't seem like you heeded the advice presented therein.
>
>What sorts of jitter attenuation techniques did you employ?
>
>I write
>SORRY. THE ONLY TECHNIQUES I USED WAS USING GOOD CABLE AND CONNECTING
>TOGETHER TWO MACHINES OUT OF THEIR DIGITAL PORTS (how naive??) I USED MANY
>DIFFERENT CABLES AND MANY DIFFERENT MACHINES. SOMETIMES I USED EXTERNAL
>CLOCKS (from an unused DAT machine connected to all inputs of all machines used in
>the
>digital transfere) SO THAT ALL MACHINES WERE SYNCHRONIZED. ONLY FEW MACHINES
>ALLOW THIS THOUGH. IF I DIDN't DO ANYTHING RIGHT LET ME KNOW, AS NOBODY ELSE
>HAS! (this includes customer service, salesmen, and ALL ENGINEERS at the studios I
>went to)
>AND THE MACHINES MANUALS CERTAINLY DON'T MENTION.
None of this really does any good. Again, attempting to minimize jitter
anywhere except in the final playback process is just futile, because the
data is reclocked at every step and the jitter spectrum changed in the
process. I think Gabe was assuming you were using an outboard converter,
which has become pretty much standard practice in the better studios these
days because the sonic benefit is not subtle.
Here is your problem. DACs aren't going to make any difference in your
transfer, but they will eliminate any differences that will occur in your
transfer. Bits should be bits. When you start hearing differences between
analogue outputs, the first places to look are at converters, because even
though bits are bits, the process of converting bits to sound is a difficult
and complex one that is difficult to do properly.
Gabe's right about his point. You're right that you are hearing something,
while he is right that you shouldn't be hearing it, and I think with good
DAC gear available, there is no reason to continue hearing it.
Case closed.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Gabe M. Wiener
First of all, stop shouting.
Second, name you the players that do _what_?
>(isn't the 1630 what your CD manufacturer got from you last year??!!)
No.
>If anyone has a DAT player that DOES DO PERFECT DIGITAL TRANSFERES, LET US
>ALL KNOW SO WE CAN TRY IT.
All properly-functioning DAT players are able to recover a digital
bitstream without corrupting the data.
>they don't SOUND the same to my ears and to any other listeners eares
It does not look like you have done _any_ controlled testing. What
converters did you use? What methods of level-matching did you
employ? What experimental controls?
>EVERYBODY SAYS THAT IT SHOULD SOUND THE SAME, AND WHO CARES ABOUT BITS
>ANYWAYS, SOUND IS IMPORTANT!!!! NOT BITS!
So we're down to the anti-engineering argument. If you want to compare
machines on sound-quality alone, then be quite sure that you know what
it is that you're testing. And from the looks of your "tests," it doesn't
sound like you do.
>I played all tapes for listening out of ONE deck per test. This one deck was
>sometimes the
>original deck, an identical deck, or a totaly unrelated deck. This used ONE d/a
>converter for all
>the tapes.
And this tells you nothing, because you have no knowledge of how good that
particular DAC is relative to anything else out there.
> I NEVER KNEW d/a CONVERTERS WERE
> IMPORTANT IN DIGITAL TRANSFERES.
They aren't. They're important in digital reproduction, and you can't
test the efficacy of a digital transfer without making sure that your
conversion is kept to a consistent level of quality.
>Thanks for telling us the source of your word-sync in such a test.
>I NEVER KNEW THAT I NEEDED AN EXTERNAL WORD SYNC TO MAKE THE PERFECT
>TRANSFERES. all THE ENGINEERES AT THE DIFFERENT STUDIOS NEVER HEARD OF
>THIS.
Once again, you might want to go out and read the veritable thousands of
pages that have been written on this subject. It astounds me that people
are so eager to re-invent the wheel instead of reading what came before
and then spending their time doing _new_ research.
>If we are incorrect, I can safely say that MOST PEOPLE think my method is the
>correct method.
Well, most people are quite often wrong....about a lot of things.
>YOU as EXPERTS should inform us or the equipment MANUFACTURERS should.
Perhaps we'd be more inclined to be helpful if you'd stop SHOUTING at us,
and if you'd stop jumping up and down asserting how certain you are about
what you know, when in fact you have come to a lot of false conclusions
about a reasonably well-understood field.
>Everyone so
>far has just said "hook up the digital out of one device to the digital in of
>another, making sure
>you use the correct co-ax or AES cable" Let us know if we are wrong!!!!
You are wrong, in certain sitautions.
>ODDLY ENOUGH, I have tryed using an external clock to all the machines. I used the
>"digital
>audio data sync" but not the "word-sync". I got no better results.
What is the source of your clock?
>IS THERE SOME LITERATURE ON DIGITAL CONNECTIVITY (published books I can buy).
Pohlmann, Rumsey, Watkinson. Over in the papers dept, we have Denni, Dunn,
Stuart, and others.
>A very reputable mastering house in LA (which has done many #1 hits) as
>a regular procedure analog outs DAT tapes and puts
>them through eq/compression and then onto a 1630. So much for digital transferes,
>but the mastering house does indeed yield excellent results.
They do this for artistic, not technical, reasons.
Gabe M. Wiener
Scott Dorsey <klu...@netcom.com> wrote:
>None of this stuff really is known for having great converters inside. I can
>attest to the fact that the 1630 has in fact what are probably the worst ADCs
>that I have ever heard in my life, bar none.
Frightening, isn't it, how many early CDs went through that thing.
>What is happening here is that you are hearing distortion which is the
>result of jitter, because you aren't using an outboard converter which
>reclocks the data. On top of this, unless you are very careful about
>using the same equipment for playback, you may even be noticing the very
>significant differences in converters between machines.
Personally I think that a lot of what he's hearing is simply a matter
of different calibrated output level between machines. If he actually
calibrated everything to 0.1 dB, I think he'd have a much harder time
of it.
>The problem isn't in the transfer, the problem is in the playback. What is
>happening is that your dupe tape has slightly different bit timing than the
>original. This is okay, it's part of the reason we can get away with so much
>in the digital process, and it's something a good playback system will
>correct for so you won't have to worry.
Well, we'd like it to be that way anyway! The problem is that since so
many people use the downright lousy converters inside the machines, digital
audio gets a bad rep from an implementational, not theoretical, issue.
>You're shouting again. Please stop that. In any case, the fact that you
>can hear differences between the cables immediately indicates that something
>is wrong. The digital systems are _designed_ to keep you from hearing this
>kind of effect, and if you _can_ hear it than you have a problem.
I'd rather that the original poster give us a little more indications of
the tests he's run so that we could know if there really _is_ a problem or
if he's imagining one. Either is quite possible.
>None of this really does any good. Again, attempting to minimize jitter
>anywhere except in the final playback process is just futile, because the
>data is reclocked at every step and the jitter spectrum changed in the
>process.
Well, in the ideal world, we shouldn't have to worry about clock jitter
at all until we get the signal to our DAC. In reality, given how many
astonishingly lousy DACs there are out there, we do tend to need to
worry about it.
Scott Dorsey
>In article <469kf4$8...@fountain.mindlink.net>,
>tojo nixon <tojo_...@mindlink.bc.ca> wrote:
>>Anyone critically LISTENING to their digital transferes knows that you can
>>never get out what you put in.
>
>and I find that with digital transfers, you can often get out what you put
>in, if you make the transfer correctly.
>
>>(analog out) you will NEVER hear the sound to be identical to the original.
>
>verifiable by doing a bit-compare in a workstation) and if your DAC properly
>attenuates jitter, the two tapes will sound identical.
[[[ stuff deleted here ]]]
>My conclusions are, either:
>
> Your testing methodology is woefully inadequate, or
> Your tests are fine and your reporting is highly unscientific.
Stop! Wait! I think the key to all of this can be found in one of
Mr. Nixon's other posts, in which he talks about having trouble with
periodic glitches when feeding his workstation from a Panasonic 4100.
It is true that, in the event of a clean and accurate transfer in
which no errors occur, a proper reclocking DAC unit will produce sound
identical to that of the original tape. However, not only does the 4100
not have a proper reclocking DAC on it, but the timing on the AES/EBU
interface is so inaccurate that it may not be possible to make copies
on another non-Panasonic deck and not get audible errors in transmission.
Therefore, if he has been using the 4100 for his tests, he is quite
likely to have precisely the sort of problems which he describes in his
post.
This is, however, strictly an implementation issue, and is easily solved.
I personally get transparent DAT-DAT dubs all the time (and in fact am
making one now), but then again I don't use a machine with a known-bad
interface.
Bill Llewellyn
>Mr. Nixon's other posts, in which he talks about having trouble with
>periodic glitches when feeding his workstation from a Panasonic 4100.
>
>It is true that, in the event of a clean and accurate transfer in
>which no errors occur, a proper reclocking DAC unit will produce sound
>identical to that of the original tape. However, not only does the 4100
>not have a proper reclocking DAC on it, but the timing on the AES/EBU
>interface is so inaccurate that it may not be possible to make copies
>on another non-Panasonic deck and not get audible errors in transmission.
>Therefore, if he has been using the 4100 for his tests, he is quite
>likely to have precisely the sort of problems which he describes in his
>post.
If the problem were data errors, whouldn't the effect be far less
subtle than Mr. Nixon's description: "The copys have less depth and
more grain ALWAYS but at slightly different frequencies depending on
the recorder used..."? If there were data errors and the errors
restricted themselves to LSBs or adjacent bits, then perhaps.
But a few MSBs or other high valued bits would get flipped in
truely random data corruption, which sounds like a dying DAT
(anything from pops and clicks to that terrible ripping sound).
To me, it sounds like the poster is encountering DAC differences,
jitter differences, and possibly level differences. I like your
idea of standardizing on a re-clocking outboard DAC.
--
--
Bill Llewellyn, http://rahul.net/thinker
"I'd never quote myself." (...me)
I'll take on ANYBODY in a missppelling contest.
tojo nixon
not just my own. My personal machine has a digital output clock noise
problem because it was manufactured before Aug 94. The actual problem is this: when
I go
digital out from my machine into another, sometimes (depending on the brand of
target machine,
so far noitced with JUST SONIC SOLUTIONS and not with Sony, Panasonic, or Tascam )
there
is audable clicks. Panasonic does a modification under warranty and this week will
modify my
machine to fix the problem. I have used other 4100s (before and after I purchased
mine) which
did not have this problem. I chose the 4100 because hands down, when I recorded
analog into it,
output from it (analog) sounded far better (clearer and deeper) than any other
machine easily
available to me (Sony, Tascam, the other brands in my area are hard to come by). I
don't know if
this "better sound" was due to better a/d or d/a in the 4100, but I was happy enough
with the
sound I heard.
Now I will try to explain my digital transfer tests as best I can. Quite possibly
the problem with my transferes might be here.
I record analog in to a DAT machine (of any brand, lets say the 3700, and we will
call this
MACHINE A) using the internal a/d converters of the machine. I then get a second
player
(MACHINE B, which we will say is another 3700 in this test). I then do a digital
transfere from
MACHINE A to MACHINE B using a 3foot store bought coaxial cable using the IEC-C
ports. I
then am left with two DAT tapes, the original and a copy. I then use MACHINE A to
play back
BOTH tapes, analog out (its internal d/a) to a power amp and speakers. In a blind
test (ie the listener does not
know which tape is being played at any particular time. They listen to one tape for
about 30sec,
and then it is ejected and the second tape is played (the same portion of material).
This process
is repeated until the listener decides that one tape is better sounding (always the
original). Once
they start to hear a difference, they become quick to point it out and they are not
fooled when
you play the same tape again and pretend that you switched them. When asked how they
know
they usually say the good one has "more depth", or "less grain".
Variations of this test that I have done are as follows:
1) I used a different brand of machine B then machine A (ie A was say a 3700 and B
was a
DA30MKII)
2) For listening tests I used the Machine A for the original tape and Machine B for
the copy,
analog out of each of the machines. Of course the sounds were very different in this
case if
machines were different brands (ie a 3700 and DA30) but similar if the same brand
(two 3700)
3)I used Machine A digitally into Pro Tools (and Sonics) and then digitally out to
Machine A for
the copy. Playback for testing was listened from machine A analog out.
4)I used Machine A to play the original tape (recorded on A) digitaly into Sonic and
used a
separate machine B to play the original tape (recorded on A) digitally into Sonic.
Listening out of
SonicSolutions analog out (I didn't know what kind of d/a was used for it was not my
system).
The two recordings out of Sonics sounded DIFFERENT and the original machine version
yielded
a better depth of field.. This test is the one that really concerned me the most. I
have been told
(but have not tryed it myself) that if I was to get a CD printed out of Sonics with
both versions on
it THEY WOULD SOUND IDENTICAL ON CD. I find this hard to believe but haven't tryed
it yet.
The tests were done using many different machines when possible for A and B, and the
"listeners" were whoever was available (myself, the engineer, a receptionist, a non
industry
friend etc.) Everybody eventually could dissern between the two tapes (copy and
original). Also
different cables and digital ports were used (AES and IEC)
If we say that the CD WOULD sound identical (of which I am not convinced), a problem
still
exists because one might use Sonics analog out for a mixdown situation (ie comping
vocals).
Also digitally storing material onto ADAT (for cheap storage to free hard disk
space) and then
back to Sonics would yield differences as well. Of this analog out situation I am
concerned
because that is why I would buy (and am planning to) a DAW. I wouldn't buy a
CD-maker
because I leave that to mastering.
Although a/d converters make big differences, I only used the DAT machines internal
ones to record program material. If
you can hear digital transfer differences on material recorded on lower quality a/d
you could
surely hear differences on the quality a/d.
tojo
Scott Dorsey
>In article <kludgeDG...@netcom.com>,
>Scott Dorsey <klu...@netcom.com> wrote:
>
>>result of jitter, because you aren't using an outboard converter which
>>reclocks the data. On top of this, unless you are very careful about
>>using the same equipment for playback, you may even be noticing the very
>>significant differences in converters between machines.
>
>of different calibrated output level between machines. If he actually
>calibrated everything to 0.1 dB, I think he'd have a much harder time
>of it.
No, because he says that he is using the same deck for playing back
both tapes, and he can hear a difference. Admittedly, this isn't very
good, since there is a significant delay involved in changing tapes.
But I agree that very minute level differences make significant
differences in sound. This is another reason why it's essential to
use an outboard DAC, since calibrating to within 1/10 dB across the
band is just plain difficult and expensive, while hooking up a DAC
is easy and cheap.
>>The problem isn't in the transfer, the problem is in the playback. What is
>>happening is that your dupe tape has slightly different bit timing than the
>>original. This is okay, it's part of the reason we can get away with so much
>>in the digital process, and it's something a good playback system will
>>correct for so you won't have to worry.
>
>Well, we'd like it to be that way anyway! The problem is that since so
>many people use the downright lousy converters inside the machines, digital
>audio gets a bad rep from an implementational, not theoretical, issue.
There is no reason for this! For $199 list you can get a decent (although
not spectacular DAC), and quite frankly it wholesales for about $99. DACs
are cheap commodity items, even though ADCs may be a lot more expensive and
hard to find.
The fact that people are blaming the _process_ and not the _equipment_ does
kind of worry me, but overall I think it's a good thing that people are
noticing stuff like this. Maybe if enough people complain, we'll start
getting reasonably-priced DAT machines that _do_ have good internal
converters.
>>You're shouting again. Please stop that. In any case, the fact that you
>>can hear differences between the cables immediately indicates that something
>>is wrong. The digital systems are _designed_ to keep you from hearing this
>>kind of effect, and if you _can_ hear it than you have a problem.
>
>I'd rather that the original poster give us a little more indications of
>the tests he's run so that we could know if there really _is_ a problem or
>if he's imagining one. Either is quite possible.
It doesn't matter if the problem is real or imaginary.... even if it's in
his mind, it still ought to get fixed. Installing decent converters never
hurt anybody, it will solve a real problem if there is one, and it will
probably solve an imaginary one as well.
>>None of this really does any good. Again, attempting to minimize jitter
>>anywhere except in the final playback process is just futile, because the
>>data is reclocked at every step and the jitter spectrum changed in the
>>process.
>
>Well, in the ideal world, we shouldn't have to worry about clock jitter
>at all until we get the signal to our DAC. In reality, given how many
>astonishingly lousy DACs there are out there, we do tend to need to
>worry about it.
Not to mention that some equipment (particularly some made by a Japanese
manufacturer whose name begins with P) has so much jitter on the outputs
that some equipment just can't latch to the clock and actual errors occur.
There is just no excuse for these kinds of problems with professional
gear; professionals need to run long cables and interchange equipment
without having to worry about weird interactions at four in the morning
while hanging upside-down in the remote truck. I have enough crap to worry
about without having to worry that I might plug two digital lines together
and not have it work.
And there is _no_ reason to have a lousy DAC, when good reclocking DACs
cost less than a reel of 2" tape.
Bill Llewellyn
In article <46cc12$p...@fountain.mindlink.net>,
>"listeners" were whoever was available (myself, the engineer, a receptionist, a non
>industry
>friend etc.) Everybody eventually could dissern between the two tapes (copy and
>original). Also
>different cables and digital ports were used (AES and IEC)
Thanks for the test explanation, Tojo. This helps a lot.
When the dub is made on machine B, machine B is extracting its recording
clock from the data stream supplied by machine A. This is done by a PLL
(phase-locked loop) in B which is supposed to supress jitter as it slaves
the machine's clock to A, but (1) it cannot and does not filter all
incoming jitter (it's a low-pass filter for phase noise), and (2) it
actually adds its *own* jitter to the data that hits the second tape in
the process. So now you have two tapes, one made in machine A and another
made in machine B with different jitter characteristics, and the data on
tape B will likely have somewhat more phase noise than A.
It's also been mentioned that the playback electronics in DAT machines
don't supress jitter very well in their clock extraction PLLs. During
playback in the SV-3700, for example (and is presumably typical of other
machines), the read-back data is passed through another PLL to extract a
clock signal; the clock is used to re-time (standardize) the recovered
data, and both clock and re-timed data are fed to the signal processing
chip and then to the DAC. As mentione above, PLLs are themselves not
jitter free, and I'm sure that if it's fed the more jittery data of tape B
it will yield a more jittery clock output than when fed the data from tape
A. An ideal machine would squash all the jitter of any tape, but we don't
live in an ideal world. Thus, it seems to me that at least the SV-3700
(and probably other units) would have deteriorated playback performance
(albeit subtle) with the more jittery tape B than with tape A.
Did all that make sense?
As Scott mentioned, you can resolve this all with a re-clocking, external
DAC like the DAC-In-The-Box from Audio Alchemy (I have one sitting in
front of me which I use for my 3700 and for my Philips CD player). Try it.
tojo nixon
Thank you very much,
I will try to obtain an outboard converter for future comparisons.
I recognise that there are a large number of variables involved in the
comparisons (which I tryed to explain on a later post) that I was making.
I think that "professional quality" digital recording equipment must leave
quite a bit to be desired given the effects that I heard. Unfortunately
"professional" is used for A-Dats, Panasonic dats, and the Apogee AD1000
converter, but all these products are quite different in sound and
quality. I see many ads for ADCs (like the AD1000, which is supposed to be
top of the line for ~$2300?) but few for DACs. Cost to me is not a factor
for these converters (as long as they are in the $2000 range or more if
they do both conversions, AD and DA). Also, in my town there is no
knowledgable dealers about interfacing the products they sell, let alone
top of the line products or procedures and my buying decision is primarily
based on what other "popular" studios and engineers use and on what I read
in magazines and lastly on _my _own _ears.
Of Digital I am a user and fan. Compared to analog, Digital is becomming
cheaper, smaller, and less of a hassle to align. I am happy with the
playback and recording quality of my machine (which is much better then an
equivalently priced reel to reel if such even exist.)
But I assure you the playback differences are not imaginary with the
transferes and all other people present in the listening tests eventually
hear it and can after that identify it much easier. (And no salesmen have
a/b'd with me yet, but I bet they wouldnt care anyways)
I referenced an article in Mix May 1991 by Bob Hodas where he observed my
problem as well. They were auditioning ADCs at the "Rocket Lab" and used
Studer Dyaxis out via Apogee DA1000 to HD-1 speakers. Their source
material was on analog tape at 15ips with SR. They used many different
ADCs (as this is what they were auditioning). After the tests they
digitally transfered from Dyaxis to 1630 (for future reference) and back
again and noticed the difference. Although this was a long time ago (91) I
think the equipment they used is still regarded as very high quality and I
am sure all precautions in cabling was taken as they are reputable people.
tojo
tojo nixon
-When the dub is made on machine B, machine B is extracting its recording
-clock from the data stream supplied by machine A. This is done by a PLL
-(phase-locked loop) in B which is supposed to supress jitter as itslaves
-the machine's clock to A, but (1) it cannot and does not filter all
-incoming jitter (it's a low-pass filter for phase noise), and (2) it
-actually adds its *own* jitter to the data that hits the second tape in
-the process. So now you have two tapes, one made in machine A andanother
-made in machine B with different jitter characteristics, and the data on
-tape B will likely have somewhat more phase noise than A.
-It's also been mentioned that the playback electronics in DAT machines
-don't supress jitter very well in their clock extraction PLLs. During
-playback in the SV-3700, for example (and is presumably typical of other
-machines), the read-back data is passed through another PLL to extract a
-clock signal; the clock is used to re-time (standardize) the recovered
-data, and both clock and re-timed data are fed to the signal processing
-chip and then to the DAC. As mentione above, PLLs are themselves not
-jitter free, and I'm sure that if it's fed the morejittery data of tapeB
-it will yield a more jittery clock output thanwhenfed the data from tape
-A. An ideal machine would squash all the jitter of any tape, but wedon't
-live in an ideal world. Thus, it seems to me that at least the SV-3700
-(and probably other units) would have deteriorated playback performance
-(albeit subtle) with the more jittery tape B than with tape A.
-Did all that make sense?
-As Scott mentioned, you can resolve this all with a re-clocking,external
-DAC like the DAC-In-The-Box from Audio Alchemy (I have one sitting in
-front of me which I use for my 3700 and for my Philips CD player).Tryit.
comment:
Yes it does sound logical and would explain my DAT to DAT
problems(which is bad if I cant play back a simple copy I make in my
machine as it is and have itsound identical) But in my dump to Sonic
Solutions of both original and copy,some type of DAC was of course used
(but unfortunately I don't know which kind.), as I understand the system
only comes with digital outs and they assume you will buy your own ADC
and DAC.
You also mention re-clocking. Doesn't Sonic's re-clock automatically
after you load the material in (ie after recording stops and the hard
drive crunches the data) and play back? Also by you mentioning
re-clocking external DAC , I assume some external DACs don't re-clock??
And yes, admittedly the differences between copy and original are subtle,
but also the differences between 16bit and 21 bit, and "super bit
mapping" to 16 bit CD are subtle as well, but to some people the
difference is important as "perfection" is strived for. To music
listeners on the street the "song" is much more important then "sound
quality". I would have to agree but both have their place.
tojo
Gabe M. Wiener
Scott Dorsey <klu...@netcom.com> wrote:
>No, because he says that he is using the same deck for playing back
>both tapes, and he can hear a difference. Admittedly, this isn't very
>good, since there is a significant delay involved in changing tapes.
Until the listening test is brought into reasonable control, I am not
convinced that anyone can consistenly produce meaningful results in
this sort of listening test.
>>Well, we'd like it to be that way anyway! The problem is that since so
>>many people use the downright lousy converters inside the machines, digital
>>audio gets a bad rep from an implementational, not theoretical, issue.
>
>There is no reason for this! For $199 list you can get a decent (although
>not spectacular DAC), and quite frankly it wholesales for about $99. DACs
>are cheap commodity items, even though ADCs may be a lot more expensive and
>hard to find.
The fact remains that in blind listening tests, I can identify different
pressings of the same data that have been bit-compared. This is where we
can begin to invoke a little proof-by-process-of-elimination by stating
that if there is no difference in recovered data, then some physical
phenomenon about the pressing is resulting in a more jittery output being
fed to the DAC.
This is quite audible on many, many DACs, including some that sell for
well into five figures. There are only a handful of DACs on which this
phenonenon is NOT audible.
Depressing, eh?
>The fact that people are blaming the _process_ and not the _equipment_ does
>kind of worry me, but overall I think it's a good thing that people are
>noticing stuff like this.
I just want to be sure that people are noticing extant, not imaginary,
phenomena.
Maybe if enough people complain, we'll start
>It doesn't matter if the problem is real or imaginary.... even if it's in
>his mind, it still ought to get fixed. Installing decent converters never
>hurt anybody, it will solve a real problem if there is one, and it will
>probably solve an imaginary one as well.
I'm not interested in imaginary problems, only real ones. I don't want to
buy new hardware to fix imaginary problems. I have to buy enough new toys
as it is to fix real issues.
>Not to mention that some equipment (particularly some made by a Japanese
>manufacturer whose name begins with P) has so much jitter on the outputs
>that some equipment just can't latch to the clock and actual errors occur.
For the clueless: PANASONIC PANASONIC PANASONIC PANASONIC PANASONIC.
As far as I'm concerned, every person who was involved in the design
and construction of the digital interface on Panasonic DATs should be
lined up against a wall and shot. The sale of so many Panasonic DAT
machines to the pro market strikes me as one of the most severe
practical jokes in the history of technology.
When are people going to realize that the things are absolute swill?
LDeeds
>the fact that you
>>can hear differences between the cables immediately indicates that
something
>>is wrong. The digital systems are _designed_ to keep you from hearing
this
>>kind of effect, and if you _can_ hear it than you have a problem.
Oh that cable WOULDN'T make a difference in sonic quality, but it quite
clearly DOES. For one of my clients, who does exclusively 20-bit
recording on his Sonic System, we did an extensive cable comparison. The
machine: Nagra D at 20-bit. The material: chamber music with B & K mics
in an X-Y pattern. The DAC: hot-rodded custom Theta Digital "24-bit"
(the client's unit). The cables we tried, all 1.5 meter: one, Kimber
Illuminati (7 hand-crafted jackets, pure silver, etc. $359 ea.); two,
Kimber PBJ reference mic cable ($79 a pair, not designed for digital);
three, Canare mic cable; four, Canare 110 ohm digital cable; five,
Apogee Wyde-Eye; six, XLO 110 ohm digital cable (don't know the model
number).
Our results: Kimber Illuminati, beyond a shadow of a doubt...Greater
detail, greater image, etc. Second, surprisingly enough, Kimber PBJ! It
only sells for about $25 a cable, but it was phenomenal. Most of the rest
were in the middle (with Canare mic cable being the surprise), the Apogee
was unfortunately not in the running...
Your digital chain is only as good as the weakest link, and cable plays a
great part in introducing (or NOT introducing) jitter in the transfer
process. Personally, I HATE the idea that spending over $300 on 5' cables
can make a difference, but when even I can hear it, and I'm no "golden
ears", I have to grudgingly admit that there is truth to the claim...
David Clementson
>Anyone critically LISTENING to their digital... (snip)
Please try this test for us:
1) Record from your DAW onto the DAT machine under test using the
DAT's digital I/O
2) Record this tape back to the DAW using the digital I/O
3) Compare the sound of the "original" file with the "copy" file, but be
SURE that the DAW is using its internal playback crystal timebase and
NOT the clock derived from its digital I/O.
4) If possible, try to get your DAW to do a bit-for-bit compare of the
two files. I believe Sound Designer II can do this.
5) Let us know what you learn. Please provide the raw data from your
blind listening tests so that Gabe can verify their statistical validity
<grin>.
My motivation for this experiment is based on the following thoughts:
The playback DAC is the same in both cases, as is the playback DAC's
clock source. The DAW rebuffers the data (I know Pro Tools does, and I
imagine Sonic must as well), so the playback DAC timing comes ONLY from
the DAW playback crystal, and is not related to the DAT clock. This
should eliminate the effect of DAT clock jitter.
The underlying assumption here is that jitter only matters at the point
of analog conversion (both A-D and D-A). This much has been pretty well
accepted in the literature. If we believe this, then any differences you
hear should be due to data pattern changes in the DAT, which you should
be able to verify with the bit-for-bit comparison.
Good luck! DC
Stefan_Schoener
indicates that something is wrong. The digital systems are _designed_ to
keep you from hearing this kind of effect, and if you _can_ hear it than
you have a problem.
>
> clearly DOES.
> Your digital chain is only as good as the weakest link, and cable plays a
> great part in introducing (or NOT introducing) jitter in the transfer
> process.
internet (once around the globe) the colors are much more brilliant and
the details are more sharp !!
;-)))
Cheers
Stefan
Stefan Schoener
music, storys and multimedia for children
phone: +49 681 65913 fax: +49 681 68250
## CrossPoint v3.1 R ##
Brandon Mathew
>
>You also mention re-clocking. Doesn't Sonic's re-clock automatically
>after you load the material in (ie after recording stops and the hard
>drive crunches the data) and play back? Also by you mentioning
>re-clocking external DAC , I assume some external DACs don't re-clock??
In digital to digital transfers, the only thing that you care about
is that the data gets from point a to point b. For that, reclocking
is not important as long as the data is recovered. When you get to the
D/A boundary is when reclocking is important. You want to strive for
each word being converted to analog at the correct time. (Well, really
you want the sample to sample time of the D/A the same as that for the
A/D, but we'll assume that the A/D was done with a stable timebase).
Just remember that jitter is important at the A/D and D/A boundaries.
As long as the data is recovered, it is not important at D/D boundaries.
--
Brandon Mathew - bra...@core.rose.hp.com
tojo nixon
>>No, because he says that he is using the same deck for playing back
>>both tapes, and he can hear a difference. Admittedly, this isn't very
>>good, since there is a significant delay involved in changing tapes.
GW wrote
-Until the listening test is brought into reasonable control, I am not
-convinced that anyone can consistenly produce meaningful results in
-this sort of listening test.
As I understand my SonicSolution test was under reasonable control (where I
dumped data from a copy and original and listened out of Sonics, its DAC
converter and all after the data was all crunched. I described the test as best I
could in a previouse post.
GW wrote
>The fact remains that in blind listening tests, I can identify different
>pressings of the same data that have been bit-compared. This is where we
>can begin to invoke a little proof-by-process-of-elimination by stating
>that if there is no difference in recovered data, then some physical
>phenomenon about the pressing is resulting in a more jittery output being
>fed to the DAC.
Finally, another poster (and a reputable one at that) CAN hear a difference,
regardless of what it is caused by. And I thought I was the only one. I assume
your tests were under reasonable control. PS: I do not put down digital, but
in fact praise it, and use it all the time. But I dont like it when people assume
perfection when theoretically possible and dont listen to the results in real life.
When you say pressings, do you mean different CDs from different
manufacturers, different CDs all from Sonics, or something else entirely?
SD wrote
>>Not to mention that some equipment (particularly some made by a
Japanese
>>manufacturer whose name begins with P) has so much jitter on the outputs
>>.that some equipment just can't latch to the clock and actual errors occur.
GW wrote
-For the clueless: PANASONIC PANASONIC PANASONIC PANASONIC
Don't put down the 4100 untill you try it. It sonically records much better then
the 3700, and all other machines of other brands (Sony, Tascam) I have
heard. Panasonic claims 20 equivalent A/D, and sounds good regardless of
the validity. If you dont like it after you try it, then slag it all you like.
Also if the DAC in my machine was the problem, the other machines playing
my tape might have sounded _better? with a _less jittery output?
Unfortunately they didn't. Also the problem with my Sonics test (when I used
its DAC to play back copys and original tapes) wouldn't be due to jittery DAC
as it would have affected original and copy in the same way and if bit
accurate and with same jitter would have sounded identical which they didn't.
Why, I do not know.
tojo
Greg Hanssen
>There is a ton of error correction in CD and DAT data configurations.
>I've heard that up to 30% of the storage volume on a CD is used for this
>purpose. Panasonic claims in their maintenance manual that even if one of
>the two head gaps in the 3700 is clogged, you will still get your data
>(I've never tried this).
On a CD, there is 1 byte of error correction for every 3 bytes of audio.
Actually, there are two 32bit ERC blocks for every two 96bit PCM blocks
and one 8bit subcode block.
On a DAT, the head spins at 2000rpm so you read two tracks (two heads)
every .03 seconds. Each track has 128 blocks (32bytes each) of data
(4096 bytes total).
Within each 4096 byte track, 1184 bytes are used for error correction
leaving 2912 for audio PCM.
As it turns out, 48khz only uses 2880 of this 2912 and 44.1khz only
uses 2646 bytes of the available 2912.
Either way, yes there is a lot of Reed-Solomon error correction on CD
and especially DAT... these codes are used to COMPLETELY fix a given
number of bad bits on the CD or tape.. Of course if there are enough
bad bits, then we have to go to interpolation etc etc, but the point is
that MOST OF THE TIME, all errors are completely fixed.
>>This also leads me to make the following statement for discussion. If
>>we are not getting "true" digital transfer using audio media, should
>>we not be using data storage for backup of our projects to preserve
>>the data as it is ment to be.
I've been using an early ZA1 DAT interface card to back up hundreds of
megabytes to an audio DAT deck over 10 feet of cheap ($3) RCA cable and
10 meters of cheap toslink fiber optic cable... I can verfiy that ALL of
my bits are being restored by the built in checksum on the backup program.
(The backup program adds more Reed-Solomon data to the stream, but this
is rarely needed). This is a fairly impressive statement when you think
about it... I'm sending hundreds of magabytes of data over the SPDIF stream
(over an hour) using the cheapest possible connectors I could possibly
find, to the cheapest DAT deck I could find (Sony :) ) recording this to
DAT, then doing the whole thing in reverse months after the fact and I
don't lose a single bit. This not only shows that you >CAN< get a perfect
copy of the data through a $3 cable or a cheap plastic fiber optic toslink
cable, but that the DAT itself maintains this data on the tape fairly well.
I'm impressed...
And one more thing... I can't explain Tojo's perceived loss of depth on
some digital dubs... but it seems some folks around here are making
the implication that JITTER can be STORED on a DAT tape! I'm having a
hard time understanding this concept. If .03 seconds of audio are stored
(compressed in time I might add) on each track of the DAT tape, how could
you possibly store the jitter? Jitter on DAT->D/A situations is the
timing difference between each sample and the bits they are made of.
If you are time compressing this data into 2880 byte blocks to be stored
on a tape, where would you put the jitter? Between tracks? I'm sure the
jitter is a lot faster than .03 seconds. When DAT tapes are played back,
you use a crystal reference to read the uncompressed data out of a FIFO..
so any jitter would be the result of a bad crystal, DAC, or SPDIF/AES
transmitter... Because of the time compression needed to stack the blocks
onto tracks of the DAT tape, I don't see how any timing errors would
make a difference.. you'll still have about 48000 or 44100 samples being
spat out based on the crystal reference, not the physical location on
the tape..
Somebody please explain this to me if I'm not understanding
something... As for the fancy cables or bad SPDIF or AES/EBU
implementations, I can't come up with any reasons why one dub would
have worse 'depth' than another.. they should be the same.. Unless
your pre-emphasis flag was getting flipped... or the source DAT deck is
not actually reading all the correct bits from the tape and you're getting
interpolated data somewhere.... hmmmmm... ya got me on that one.
--
--Greg <Han...@netcom.com> (714)-551-5833 4961 Barkwood
Zefiro Acoustics: SPDIF interface cards for the PC. Irvine, Ca. 92714
Bill Llewellyn
>
>>Not to mention that some equipment (particularly some made by a Japanese
>>manufacturer whose name begins with P) has so much jitter on the outputs
>>that some equipment just can't latch to the clock and actual errors occur.
>
You have five of these, Gabe? (Sorry, I had to....)
>As far as I'm concerned, every person who was involved in the design
>and construction of the digital interface on Panasonic DATs should be
>lined up against a wall and shot. The sale of so many Panasonic DAT
>machines to the pro market strikes me as one of the most severe
>practical jokes in the history of technology.
I look at the 3700 as being semi-pro, not full-blown pro gear. As for its
clock jitter, I've been scanning the schematics to see what might be going
on. The trouble is in phase-locked loop implementation, and I've got some
ideas on possible tweaks (I've got some experience in PLLs). There may be
a way to salvage these beasts. I'm most interested in the recording chain,
as outboard DACs for playback with reclocking are getting pretty
affordable.
Bill Llewellyn
Michal Jurewicz <my...@styx.ios.com> wrote:
>klu...@netcom.com (Scott Dorsey) wrote:
>
>
>> And there is _no_ reason to have a lousy DAC, when good reclocking DACs
>> cost less than a reel of 2" tape.
>> --scott
>
DAC-In-The-Box, by Audio Alchemy. $199.
ke...@infoserv.com
it was written:
-When the dub is made on machine B, machine B is extracting its recording
-clock from the data stream supplied by machine A. This is done by a PL
-(phase-locked loop) in B which is supposed to supress jitter as itslaves
-the machine's clock to A, but (1) it cannot and does not filter all
-incoming jitter (it's a low-pass filter for phase noise), and (2) it
-actually adds its *own* jitter to the data that hits the second tape in
-the process. So now you have two tapes, one made in machine A andanother
-made in machine B with different jitter characteristics, and the data on
-tape B will likely have somewhat more phase noise than A.
This is not correct.
In now way does this matter. Jitter affects DACs *NOT*
tapes in digital to digital transfers.
-It's also been mentioned that the playback electronics in DAT machines
-don't supress jitter very well in their clock extraction PLLs. During
-playback in the SV-3700, for example (and is presumably typical of other
-machines), the read-back data is passed through another PLL to extract a
-clock signal; the clock is used to re-time (standardize) the recovered
-data, and both clock and re-timed data are fed to the signal processing
-chip and then to the DAC. As mentione above, PLLs are themselves not
-jitter free, and I'm sure that if it's fed the morejittery data of tapeB
-it will yield a more jittery clock output thanwhenfed the data from tape
-A. An ideal machine would squash all the jitter of any tape, but wedon't
-live in an ideal world. Thus, it seems to me that at least the SV-3700
-(and probably other units) would have deteriorated playback performance
-(albeit subtle) with the more jittery tape B than with tape A.
There is not such thing as "jittery tape".
The only portion in the chain that is affected by jitter are the A/D
converters while recording and the D/A while listening. Jitter is
not a factor in transferring the data from one tape machine to another.
In this case bits *IS* bits.
Jitter is the uncertainty in the clock and unless you are sending data to DACs
forget about jitter.
Kent
--
/* "There is no king who has not had a slave among his ancestors and */
/* no slave that has not had a king among his." ---- Helen Keller */
/* Kent L. Shephard ----- K. L. Shephard Consulting */
tojo nixon
people with high end DAW can verify it usung a bit check?) If you say jitter would
not be the problem then something else might be. Who knows, maybe majic? But is
seems that enough people _hear the problem so it does exist, weather it is the
equipment or _user _error. This is what I would like to know so I don't have this
problem.
tojo
Monte P McGuire
Steve Turadek <tur...@cisco.com> wrote:
>I'm having a hard time buying this whole thread.
>
>agreed: across a D/D boundary, jitter doesn't matter.
>
>I'm choking on the notion that it even matters across the D/A interface.
>okay, I concede it might matter if it's severe enough.
>
>But I'm thinking the output data stream to the DAC is going to be
>synchronized with a quartz clock, not synchronized to a vagaries of the
>datastream coming off the tape/disk/spacedish/whatever.
That's not completely correct: there's no flow control available to
the receiver, so it has to extract the clock based on the data stream;
there's no way to tell the sender to send more bits because the
buffer's empty or hold back for a while because the buffer's full.
This usualy means using a PLL to extract the sample clock and while
that approach can work well, it is still dependent on the nature of
the data stream's clock.
You're correct that in essence, the data is clocked off of a quartz
oscillator at the first stage, but in later stages separated by
digital interfaces, the timing errors are controlled by each stage
that passes the signal since each stage must recover the clock from
the data stream only. And also, the problem is not minute speed
variations caused by a few PPM of crystal drift, it's uncertainty of
the clock edges that causes modulation and corruption of the signal.
There are a lot of other ways to mess a sample clock up besides a poor
PLL. If you run the clock through some asymmetric logic chips (like
TTL as opposed to CMOS), you may still have one clock edge that's
clean, but the other edge may be different because the rise and fall
times of the logic family are not symmetric. So, if the resulting
clock is good on only one of the two edges (rsing or falling) and the
DAC clocks off the other edge, you can get problems even when the PLL
is good.
It's really all dependent on the devices in question. I'd like the
problem to go away, but it's readily apparent to anyone who uses bad
devices like the Panasonic 3700; you're going to get odd behavior due
to the way they handled the clock and to simply pretend it doesn't
exist is foolish.
Regards,
Monte McGuire - N1TBL
mcg...@world.std.com
David Clementson
>But I'm thinking the output data stream to the DAC is going to be
>synchronized with a quartz clock, not synchronized to a vagaries of the
>datastream coming off the tape/disk/spacedish/whatever.
Strange but untrue! At least for a CD. The CD's DAC clock is
often recovered from the laser diode/spinning disk servo, hence the
jitter, etc. This is the stupidest possible scheme. I heard a story to
the effect that this was done in order to avoid the FCC RF emission
compliance requirements for consumer hi-fi gear. The crystal oscillator
would have made the player a type of computing device requiring such
compliance.
The data should, of course, be resynchronized to a (low jitter) crystal
clock via a FIFO buffer. There is a Japanese patent on this clocking
approach, though, but I forget which company owns it.
I don't know how DATs are built inside, but I'll try and find out.
Anyone? I do know that the Pro Tools DAW does use a FIFO and a
low-jitter DAC clock. I would imagine all other DAWs do as well,
although I've not seen any schematics other than for Pro Tools.
Incidentally, a paper was delivered at the 1993 or 1994 AES convention by
Dr. Gary Schwede on this very topic. You might want to find the
preprint.
DC
Stefan Heyer
time and energy on this ..ahem.. "debate" ?
Stefan
Peter Kerr
I read somewhere of research which found listeners identifying
a difference on A - B tests which came solely from their belief
that A & B were different. In fact it was the same source used
for both channels.
Granted DACs are different, and some are so different as to
actually sound different, but how can you eliminate the
psycho-acoustic effect of people wanting to hear a difference?
--
Peter Kerr bodger
School of Music chandler
University of Auckland neo-Luddite
Greg Hanssen
>In article <DGz5p...@infoserv.com>, <ke...@infoserv.com> wrote:
>>There is not such thing as "jittery tape".
>Actually, there can be. In the recording process, be it in tape, hard
>disk, magneto optical disk, floppy disk, MD, or even in the transmission
>of serial data down a serial communications path such an ethernet link,
>jitter is a very real and a serious system consideration. I've dealt with
>it for years in hard disk read channels - it's quite real. Bit positions
>can easily be dithered in an unwanted fashion from their desired position
>in any media during recording, DAT included.
Are we talking about the same type of jitter here? If there is jitter in
the incoming signal, this will not be stored on the tape because the signal
is buffered and time compressed into .03 second chunks of data on the tape.
If these bits are not read back correctly due to 'jitter' then this is
something else entirely... Granted if the data is not written correctly
to the tape then parts of it may not get read back correctly, thus causing
the interpolation system to come into play (if the data is that bad) and
then you get the audiable difference... but don't confuse jittery bits on
the DAT tape with the jitter we're discussing in the SPDIF or AES/EBU
stream.. these are entirely unrelated.
>I think I know the next question: why is that a concern? Even if there is
>jitter, if there it is not severe enough to cause data corruption then
>just get rid of the jitter before the DAC. Well, it's up to the PLL at the
>DAC to squash this jitter, which it may not do well. Then you hear it.
Well this would be yet a 3rd type of jitter being introduced by the FIFO
output clock.... most DATs I've seen have seperate crystals to output
32khz, 44.1khz and 48khz audio.. As do the DAL digital I/O cards. Our
ZA2 card uses a programmable PLL to synthesize these (and other) rates
from a 6.144mhz master xtal.
>And it also seems very plausible, given the non-idealities of some of the
>DAT equipment that we've discussed here, that a dubbed tape may have more
>jitter that an original. And if that makes it to the DAC, and the dub
>would sound worse.
uhm... jitter? maybe you mean data errors.. Any large buffering system
should eliminate any source jitter.. that's not to say of course that it
couldn't generate its own jitter.. but this is different.
>>The only portion in the chain that is affected by jitter are the A/D
>>converters while recording and the D/A while listening. Jitter is
>>not a factor in transferring the data from one tape machine to another.
>>In this case bits *IS* bits.
>Actually, in an earlier part of this discussion another netter noted that
>a jitter conflict between Panasonic 4100 models connected together for
>dubbing caused data transmission errors.
yes, and again, these are data errors caused by jitter.. but the jitter
itself is not 'stored' on the tape.
>>Jitter is the uncertainty in the clock and unless you are sending data to DACs
>>forget about jitter.
>It's very important at the DAC. Absolutely. No arguement at all. And it
>can matter elsewhere, if severe enough. And if it's present in the source
>data headed for the DAC, you may hear it in the DAC because it may not get
>filtered out in the retiming PLL(s) as much as we'd all like it to be.
True.
> So
>ostensibly a jittery tape may actually sound worse than the original.
>Strange thought. Anybody with two 3700s out there who'd like to try this?
Jittery tape? you mean a tape with data errors or interpolated data (that
may have been caused by jitter at a much earlier stage)
Laurence Pearce
Toyo has sarted a fascinating debate here.
As a computer scientist it has taken me a long time to get away from the
"if its digital then it must be bit-accurate" mindset.
For the benefit of those who still believe digital audio transfer and
recording to be equivalent to computer data transmission and storage,
here are the key differences as pointed out by people on this thread:
1). Digital audio works in real time. Therefore Jitter *does* exist
because DACs and AtoDs are sensitive to the timing of data arrival
(unlike a LAN or hard disk, which is based on packets or blocks of data).
2). Becuase of the need for real time record and playback, DAT storage is
not 100% error corrected as computer data is. Hence, in addition to
total losses causing clicks and pops, it may well be possible to hear
audible artifacts resulting from interpolation between bad samples (a
floppy disk drive retrieving a program would never *guess* values for the
missing bytes in a bad sector!).
Hope this summary helps people's understanding of the debate.
Laurence Pearce
London, UK.
Brian Drummond
>I'm having a hard time buying this whole thread.
>agreed: across a D/D boundary, jitter doesn't matter.
>I'm choking on the notion that it even matters across the D/A interface.
>okay, I concede it might matter if it's severe enough.
(snip)
>even detestably cheap quartz clocks have long term drift errors of just a
>couple parts-per-million, and short-term drifts much lower than that.
>most commercial stuff is *way* better than this. or perhaps DAT designers
>are using RC-networks for timebases? I don't think so.
DAT designers are using crystals of some sort. (Sometimes WAY off
frequency, as though they get confused between series and parallel
resonance. I do too, but at least I check :-)
But DAC designers? You have to be looking at the more expensive
Meridian, Linn* ,Apogee, Prism(Gabe's favourite) and so on, DACs
before you find a crystal oscillator in the PLL.
Most, using the Yamaha or Crystal SP-DIF (or AES) receiver chips do
indeed use R-C oscillators. The resulting jitter is, of course, way
higher than it need be.
* Before you read further, I worked for Linn, so bear in mind I _may_
be biased here. I've never dared ask Gabe what he thinks of my DAC!
Even after a crystal oscillator, many DACs (not *) take the final
clock from the (noisy) digital filter to the DAC itself, thus putting
jitter back in.
So I think Gabe's right to defend digital audio on theoretical grounds
(though with an open mind on some of the limits) and equally right to
be intensely critical of some areas of practice.
>I could be wrong about this, never having designed a DAT machine or a CD
>player, but I've designed plenty of other stuff that works along like
>lines and wonder if the people worrying about jitter here own stock in
>dejitterbox machine producers. or have a psychological need to buy
>expensive stuff (uh...like me :( )
What's slightly different is that (even in a 20ish kHz bandwidth,
picoseconds (or at least tens of..) seem to be important, in ways that
sometimes don't quite make sense.
Sure we know a lot about hearing with regard to the ear, but I don't
think we've much idea what the brain does with the result.
(It makes us want to buy expensive stuff, I suppose)
- Brian
Bill Llewellyn
Laurence Pearce <la...@cix.compulink.co.uk> wrote:
>
>1). Digital audio works in real time. Therefore Jitter *does* exist
>because DACs and AtoDs are sensitive to the timing of data arrival
>(unlike a LAN or hard disk, which is based on packets or blocks of data).
>
>2). Becuase of the need for real time record and playback, DAT storage is
>not 100% error corrected as computer data is. Hence, in addition to
>total losses causing clicks and pops, it may well be possible to hear
>audible artifacts resulting from interpolation between bad samples (a
>floppy disk drive retrieving a program would never *guess* values for the
>missing bytes in a bad sector!).
I think the previus poster's assertion works on the hypothesis that some
fairly frequent occurance of uncorrectable errors in data can change the
character of the playback audio in subtle fashions, yielding the lack of
depth, graininess, and so forth, that the originator of this whole thread
mentioned. Hmmm. To be quite frank, I wouldn't think so, but I'm certainly
willing to be corrected! Does anyone out there have hard data on this?
Bill Llewellyn
Greg Hanssen <han...@netcom.com> wrote:
>Bill Llewellyn <thi...@rahul.net> writes:
>
>>In article <DGz5p...@infoserv.com>, <ke...@infoserv.com> wrote:
>
>>>There is not such thing as "jittery tape".
>
>>can easily be dithered in an unwanted fashion from their desired position
>>in any media during recording, DAT included.
>
>Are we talking about the same type of jitter here? If there is jitter in
>the incoming signal, this will not be stored on the tape because the signal
>is buffered and time compressed into .03 second chunks of data on the tape.
The data is stored as individual bits. These can contain jitter from their
intended positions. If you attach a time interval analyzer (HP-5372 or
similar) to the raw read-back signal from the DAT head drum, you'll see a
time distribution due to recorded jitter. This jitter has various causes,
but it's there and the playback PLL has to (1) lock to those dancing bits
and (2) try and filter jitter out before it hits the DAC. If it doesn't do
this well, the DAC gets it.
>If these bits are not read back correctly due to 'jitter' then this is
>something else entirely... Granted if the data is not written correctly
>to the tape then parts of it may not get read back correctly, thus causing
>the interpolation system to come into play (if the data is that bad) and
>then you get the audiable difference... but don't confuse jittery bits on
>the DAT tape with the jitter we're discussing in the SPDIF or AES/EBU
>stream.. these are entirely unrelated.
No confusion. You mention bit errors. The DAT system is generally well
equipped to deal with these, and when they overwhelm the error correction,
one gets interpolation (clicks/pops) or muting. Severe enough jitter can
cause these, along with dirt, etc. But jitter in the SPDIF or AES/EBU
stream would also be related to recorded jitter by the amount by which the
playback PLL could or could not supress bit shift-based jitter coming from
the tape itself. PLLs are not brick-wall filters against jitter -- if I
read my 3700 diagrams right, all that stands between bit shift on the tape
and jitter in the DAT's digital outputs would be PLLs. Yes they'll filter
some, but will pass some. And maybe add some.
>Well this would be yet a 3rd type of jitter being introduced by the FIFO
>output clock.... most DATs I've seen have seperate crystals to output
>32khz, 44.1khz and 48khz audio.. As do the DAL digital I/O cards. Our
>ZA2 card uses a programmable PLL to synthesize these (and other) rates
>from a 6.144mhz master xtal.
Two points: First, a synthesizer PLL in a PC audio card or anywhere will
produce a clock which is jitterier that the crystal reference, unless one
uses a *very* stable VCO, such as an XVCO. So once you pass a nice, clean
crystal clock through a PLL, you've foregone that nice non-jittery crystal
signal for a somewhat jitterier one. And the lower your crystal reference
frequency, the greater the jitter in the PLL.
Second, a PC card, if I understand it correctly, calls for bursts of data
from the hard disk as it needs them. It then fifo's the data through a
crystal controlled fifo buffer and out it goes, crystal clocked. This
premits the fifo crystal to govern the entire throughput operation. Great
setup for a crystal-based fifo and DAC! The 3700, on the other hand -- if
I read its documentation right -- gets serial data pouring in from a
constant-speed head cylinder -- which it can't stop when a fifo gets full
or accelerate when the fifo gets empty -- and therefore uses a PLL to
re-time data and extract a clock based on the data itself, not on a local
crystal. This clock finds its way through yet another PLL and then hits
the DAC. I *wish* there were a crystal clock based fifo!! But the clock
appears PLL based. To wit: If the 3700 had a crystal-based fifo and DAC,
it wouldn't have the.... um.... less-than-ideal reputation it has for DAC
and I/O jitter.
>>And it also seems very plausible, given the non-idealities of some of the
>>DAT equipment that we've discussed here, that a dubbed tape may have more
>>jitter that an original. And if that makes it to the DAC, and the dub
>>would sound worse.
>
>uhm... jitter? maybe you mean data errors.. Any large buffering system
>should eliminate any source jitter..
Yeah.... though the key operative word, I think, is *should*. As PLLs go,
though some are better than others, they just don't stop all incoming
jitter. Their output jitter is a function of their input jitter (they're
just a low-pass filter for phase modulation, really), and can also add
their own. In an on-demand system like a hard disk playing into a fifo,
crystal-based buffering works for very clean output. In an incoming
data-slaved system like an SPDIF connection or DAT playback, you've got
PLLs and their anomalies.
>>>Jitter is the uncertainty in the clock and unless you are sending data to DACs
>>>forget about jitter.
>
>>It's very important at the DAC. Absolutely. No arguement at all. And it
>>can matter elsewhere, if severe enough. And if it's present in the source
>>data headed for the DAC, you may hear it in the DAC because it may not get
>>filtered out in the retiming PLL(s) as much as we'd all like it to be.
>
>True.
That's my whole point. :) I'm saying that the jitter source can extend all
the way back to bit jitter on the tape, at least in mid-class DATs.
(This has gone on a while.... Should we retire this thread, anyone?)
Keith Hollister
>I would question the validity of doing a test like this using a
>soundblaster, too. The sound is crap and they pick up a mass of
>electrical noise from the PC electronics, although it is less in some
>machines than others. The analog circuitry is not too hot either.
I realize the SB is crap. I originally posted this because I was
suprised that differences were audible with such a poor DAC.
______
Keith Hollister
kei...@gate.net
Gabe M. Wiener
Bill Llewellyn <thi...@rahul.net> wrote:
>>For the clueless: PANASONIC PANASONIC PANASONIC PANASONIC PANASONIC.
>
>You have five of these, Gabe? (Sorry, I had to....)
Four, actually.
It's funny. I actually had to stop and think there. I've finally reached
the point where I have lost track of the number of DAT machines. The other
day, I found a Denon DTR-80P that I forgot I had, in a closet at the studio.
>I look at the 3700 as being semi-pro, not full-blown pro gear.
The only DAT machines that I consider to be real pro gear are things like
the Sony 7000 series, the Otari DTR-90, etc....machines that, for instance,
let you receive from one digital source and sync to another.
Greg Hanssen
Bill Llewellyn <thi...@rahul.net> writes:
>The data is stored as individual bits. These can contain jitter from their
>intended positions. If you attach a time interval analyzer (HP-5372 or
>similar) to the raw read-back signal from the DAT head drum, you'll see a
>time distribution due to recorded jitter.
exactly.. you may find jitter, but this is unreleted to the SPDIF or AES
source when the tape was recorded.
> This jitter has various causes,
>but it's there and the playback PLL has to (1) lock to those dancing bits
>and (2) try and filter jitter out before it hits the DAC. If it doesn't do
>this well, the DAC gets it.
hmm.. my only point is that (like a hard drive system) the DAT tape is
read in huge 'chunks' of data.. these chunks are stored in memory so
that the C1 and C2 Reed Solomon codes can be re-inserted to correct
a given number of bad bits.. when this 'block' of data has been correctly
re-assembled, THEN it is sent out the FIFO (using the crystal).. so in
a sense, the DAT playback is very similar to the hard disk.
>(This has gone on a while.... Should we retire this thread, anyone?)
Sorry.. I don't have all the answers either.. this whole 'recording SPDIF
jitter onto a DAT tape' seems a bit fishy to me...
Bill Llewellyn
Greg Hanssen <han...@netcom.com> wrote:
>Bill Llewellyn <thi...@rahul.net> writes:
>
>>but it's there and the playback PLL has to (1) lock to those dancing bits
>>and (2) try and filter jitter out before it hits the DAC. If it doesn't do
>>this well, the DAC gets it.
>
>read in huge 'chunks' of data.. these chunks are stored in memory so
>that the C1 and C2 Reed Solomon codes can be re-inserted to correct
>a given number of bad bits.. when this 'block' of data has been correctly
>re-assembled, THEN it is sent out the FIFO (using the crystal).. so in
>a sense, the DAT playback is very similar to the hard disk.
Hi, Greg.
I agree completely about the chunks, the fifo buffering, the re-
assembling process, and such. However, in the 3700, I really don't
think the fifo feeding the DAC is clocked by a crystal. I think the
*entire* playback digital processing system, DAC included, is clocked
by the playback PLL, and not by a crystal. And the playback PLL uses
the bits on the tape as its sole source of timing information.
If the PLL clock drives everything, DAC included, then any jitter it
passes and/or creates hits the DAC. Therefore, if one has a tape
recorded with bit jitter and jitter sneaks through a soft PLL design,
you'll hear it. I think the crystals in the 3700 are used for servo-ing
the head cylinder during recording and playback, and for generation
of the sampling clock during recording only.
If I'm all wet on this (the 3700 service manual doesn't show *everything*),
do set me straight. I *wish* the DAC were crystal clocked!! But the 3700
playback has a reputation for excessive jitter both at the DAC and in the
SPDIF and AES/EBU digital outputs. Where does it get all that jitter if
it's all clocked directly by a crystal?
(And I was the one who mentioned how long this thread had gone....) :}
Gabe M. Wiener
So long as the DAC attenuates it properly, this is correct. Sadly,
most DACs don't do too good a job.
>But I'm thinking the output data stream to the DAC is going to be
>synchronized with a quartz clock, not synchronized to a vagaries of the
>datastream coming off the tape/disk/spacedish/whatever.
No. The DAC derives its sync from the incoming signal, not from a
crystal sync source.
>even detestably cheap quartz clocks have long term drift errors of just a
>couple parts-per-million, and short-term drifts much lower than that.
It isn't that. it's a question of: How is a very accurate clock treated
*after* it's generated?? How much of the clock signal's bandwidth is
preserved during transmission? The less bandwidth, the fuzzier the
state changes become.
>I could be wrong about this, never having designed a DAT machine or a CD
>player, but I've designed plenty of other stuff that works along like
>lines and wonder if the people worrying about jitter here own stock in
>dejitterbox machine producers.
Uh, no. I don't own stock in them. I just know what I can hear, and can
prove that what I hear has a basis in reality, not fantasy.
Gabe M. Wiener
Peter Elsea <el...@CATS.ucsc.edu> wrote:
>As GW often points out we can use very minor auditory cues to identify a
>sound. In this case my guess is it's the artifacts of interpolation.
>Error correction is going on somewhere from 5 to 300 times a second,
>depending on the condition of the machine and tape.
But don't forget: We can know UNAMBIGUOUSLY whether our data is intact
or not. In particular, we can always know if there is any interpolation
going on. In my testing I have heard differences under blind listening
conditions from two sources containing identical data, when it was known
without ambiguity that there was no interpolation going on.
Stefan Heyer
>In article <46naca$h...@inn.aball.de>,
>Stefan Heyer <he...@massive.aball.de> wrote:
>>Scott and Gabe (and probably others), why do you spend so much of your
>>time and energy on this ..ahem.. "debate" ?
>(deleted)
>Because it's a chance to actually explore a field of engineering that
>we don't have all the answers to.
>
>Because it's a challenge when you're confronted with provable,
>demonstrable facts that tell you that a lot of what you assumed about
>digital audio was wrong.
>
Gabe,
earlier in this thread,you stated
>My conclusions are, either:
> Your testing methodology is woefully inadequate, or
> Your tests are fine and your reporting is highly unscientific.
["Your" - Tojo Nixon´s]
>Digital transfers can indeed sound different, but the phenomena that >brings that about is reasonably well understood.
(and indeed, imho it _is_ reasonably well understood.)
Apart from that, what I meant in my first post cited above was the
_style_ of the "debate".
Stefan
Clive Backham
of what is going on, I'll try once again....
Let's take the case of making a digital copy from one DAT to another.
Everyone seems agreed that the copy will have the same bits on it. Now,
as I understand it, when a DAT machine plays back a tape, it will read
blocks of data into a buffer and then clock it out to the DAC according
to some internal crystal clock. This buffering implies that, given two
tapes with the same bits on them and played back on the same machine,
the resultant playback jitter should be the same for the two tapes
(being an artifact of the DAT player's output circuitry after the
buffer).
BUT....
Gabe M. Wiener (ga...@panix.com) wrote:
: The point here is that we are long past the days when digital copies
: were considered exact if they were bit-for-bit accurate. We know that
: that's easy to do. What we are finding is that due to some rather
: poor equipment design, jitter from our playback devices can affect
: what we hear. And it seems that jitter during recording affects the
: media to the point that the result is more jittery playback.
: The net result is that it seems that jitter can be cumulative or
: transferable, for all the wrong reasons.
Now, Gabe seems to be saying that what gets recorded onto the copy tape
somehow causes the resultant playback to have a different jitter
characteristic than the original tape of which it is a "clone". How can
this be? It strikes me that any digital copy should preserve whatever
jitter (if any) was formed at the initial A/D conversion step when
creating the original. Gabe's choice of words seems to imply that he
knows the process by which the jitter burned into the copy is different
than that of the original. Please could someone explain. (And please,
no references to DACs. Everyone seems to be talking about DACs not
dealing properly with jitter, and I am fully aware of this fact, but
this seems a complete red herring since DACs are not involved in a
digital copying process).
Clive Backham
McDonnell Information Systems, UK
email: cbac...@uk.mdis.com
Monte P McGuire
Stefan Heyer <he...@massive.aball.de> wrote:
>
>What worries me more are the procedures people use for their listening
>tests. Everybody just tells you they "hear a difference" or even give
>poetic descriptions of this difference. But what did they actually do?
>I suspect they just muted two channels on their mixer and dropped in two
>others with about the same gain and then decided there was a difference
>(and this may even be one of the better designed "testing procedures"
>of which we are just told the results). And many people simply rely on
>"long experience" or "golden ears".
Here's my test. Monitor the analog output of a Panasonic 3700 (either
through headphones or the main outputs) and monitor a signal while
recording it to tape. Then stop the machine, rewind it a bit and
listen to that signal. Respond to any differences that you hear.
The only difference in the two scenarios is the source of the data
clock; the gains are identical, the signal path and cabling is
identical and the program is identical. Sounds like a good test to
me...
The only bug is that it's not a blind test. With some help from an
assistant and the assumption that the source data can be played twice
without _any_ differences, you could turn this into a single blind
test.
>Quite frankly, everybody in the field of, say, biomedical or
>psychological research would openly laugh about this or silently weep and
>say nothing. But this is what half of the discussions in this list are
>based upon.
If someone were to have you compare a nice full range speaker to a
table radio using a non blind test and you scored perfectly, would you
still want to perform a blind test? Perhaps there's some intellectual
dishonesty involved in not going the blind route, but how much effort
do I have to expend to convince myself that I know what I know?
Non subtle problems like this usually arrive in the other order: you
make a dump of a digital recording into a machine and you then verify
the recording by playing a short segment of it and you discover that
it sounds very different. Do you instantly doubt your senses because
your methodology is not reliable or do you try to see why and how the
recording 'changed'?? You've been listening to that recording the
entire day (or week) and you know most of it pretty intimately, so if
you hear somthing has changed, why is it OK to believe that you're
simply confused??
If I'm in the business of making things sound good, then how do I know
when something that I think sounds good really does sound good? What's
the cost when I get it wrong? What's the cost of trying to verify
that I'm right? There are a lot of decisions that are made completely
open loop without any concern for methodology and while it may not be
the most correct plan of action, sometimes you have to take the risk
of being wrong and spend your time doing something creative rather
than analytic; it's the tape that I'm trying to change, not my mind.
I keep my mind but the client gets the tape.
Scott Dorsey
>
>This thread started off with the question of digital transfers, which
>using some mid-priced studio dat __in proper condition__ shouldnæ„’
>cause too many audible problems (I never heard any). Of course, if
>somebody uses inferior DACæ„€, itæ„€ another story. But thatæ„€ a point
>almost everyone on this list will agree to anyway. So all this prolonged
>discussion about jitter here and there seems a bit far out to me.
I have heard a lot of effects just where the analogue input doesn't
sound like the analogue output. Do an A/B test yourself, and see. This
indicates to me that there are either inferior converters in most
mid-priced studio DAT decks, or something weird is going on. (And yes,
I level matched to within .5 dB, which isn't great but is reasonable).
>What worries me more are the procedures people use for their listening
>tests. Everybody just tells you they "hear a difference" or even give
>poetic descriptions of this difference. But what did they actually do?
>I suspect they just muted two channels on their mixer and dropped in two
>others with about the same gain and then decided there was a difference
>(and this may even be one of the better designed "testing procedures"
>of which we are just told the results). And many people simply rely on
>"long experience" or "golden ears".
This is indeed the problem. This is why I have been encouraging people
to use outboard DACs. If you use an outboard DAC and switch the digital
line, you get _no_ level differences between the decks, and _no_ frequency
response differences. If you continue to hear a difference with this
configuration, then there is a significant effect. However, between the
poor control of the analogue section and the fact that there are
jitter issues on the digital side, most of this discussion is indeed
meaningless. But that's not to say that there aren't problems which
will be solved by an external reclocking DAC; it will make it possible
to measure things accurately, as well as solving most jitter problems
that may exist.
>Quite frankly, everybody in the field of, say, biomedical or
>psychological research would openly laugh about this or silently weep and
>say nothing. But this is what half of the discussions in this list are
>based upon.
Well, I have a degree in experimental psychology and experimental design
and I have seen an awful lot of this kind of thing in peer-reviewed
journals, so I think you are underestimating just how pervasive the
problem is. It's bad in the audio world (and you can look at that
garbage from the AES show about 96 KHz conversion for a good example of
just how awful it gets), but it's pretty bad in the outside world too.
>Of course i agree with you in that there are problems with digital stuff.
>And I appreciate it if people give their two cents about some equipment
>they worked with - I have asked for such on this list myself.
>
>But before I have to search through lengthy discussions of this sort i悲
>rather hear from somebody who carried out a _proper_ listening test and
>giving us a complete description of the procedures, as we get it in
>decent scientific publications. This would be an acceptable basis and
>motivation for threads like these.
I have done so in the past, and I reported that if you have good
equipment that reclocks properly, the effects discussed in this thread
are minimal. It may or may not be possible to hear the effects of
jitter, but that's academic because you ought to have an outboard
DAC anyway.
>Apart from that, as i replied to gabe before, my primary concern in my
>post cited above was the _style_ of the discussion. If you go to great
>lenghth about the opinions of someone who just SHOUTS in a self righteous
>and somewhat confusing manner (remember how it all began?), what will a
>newbie think when he politely asks a little question and gets 2 lines as
>a reply or is completly overlooked?
It really doesn't matter who is right. If everybody had an accurate
outboard converter, they'd at least know if they heard effects with
some substantial evidence. That's worth the money for a DAC right there.
The DAC fixes imaginary problems as well as it fixes real ones, so
it's not worth arguing about.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
robert bristow-johnson
In article <46vb4j$6...@panix.com>, Gabe M. Wiener (ga...@panix.com) writes:
>In article <8...@audioheads.com>,
>robert bristow-johnson <rob...@audioheads.com> wrote:
>>Fundamental Axiom: For two digital recordings to sound different
>> when played on the exact same gear, there must
>> be a numerical difference between the two
>> digital recordings.
>
>This axiom has been refuted experimentally by many people, myself
>included.
>
remember the presumtions of the axiom: numerically identical
digital recordings played out the same gear. in fact, if you
read the whole post (i anticipated this argument from someone,
but not gabe), i went further to say two numerically identical
recordings on the same hard disk, played out the same gear
(presumably high quality with little DAC timing jitter, i should
have said that more clearly) so that jitter is not the issue. if
gabe says he can hear the difference between two such recordings,
i say he can also hear the 'difference' between the same
recording played out twice, one after another.
>>the justification of the Fundamental Axiom simply being one of
>>cause and effect. the numbers recorded on the DAT (or the HD) are
>>the cause and how the DAT sounds is the effect.
>
>Bzzt. Not quite. The causal relation of sound to digital audio is
>a) WHAT the numbers are, and b) WHEN the numbers are.
>
is it just me or is the apparent tone of the response above
patronizing? whether or not, i'll try to just respond to the
content of the response rather than the tone.
'WHEN' (i s'pose you mean jitter, because i'm not prepared to deal
with the possibility that a recording sounds better or worse today
than it sounded yesterday) is an issue of the quality or
performance of the recording and playback gear. 'WHEN' is not
a quantity recorded on digital audio recordings (before you press
'Bzzt', read the paragraph below). the recording presumes all
samples are at equally spaced times, if they're not, your
recording ADC (and/or associated hardware) has problems. if a
high quality recording (i.e. recorded samples _do_ represent
instantaneous voltage samples at very nearly equally spaced times)
is played back through poor gear, those equally spaced samples
are output at unequally spaced times and you hear jitter error.
the issue of the bits or samples on DAT being recorded at jittered
times is dealt with by buffering the data from when it's pulled
off the DAT to when it's output to the DAC. any unequally spaced
times are forgotten about by the time data gets to the DAC. the
jitter issue there is how good the clock signal is that updates
the samples to the DAC each sampling time. in fact, jitter in
the digital recording medium, if it were a problem, is worse
in a hard disk when data is blapped out at you in 512 byte
blocks (with some real time gap in between). there better, the
hell, be buffering to deal with that and there is. if the recording
or playback jitter on the tape is so bad that you end up dropping or
repeating bits or entire samples, you've got bigger problems and the
two recordings will not compare as numerically identical.
>The axiom addresses a) but not b).
>
b) is not an issue with true digital-to-digital transfers unless
your gear is so bad you end up dropping or repeating data.
>>the experiment Duncan ran was taking some recording, transfering
>>to DAT, transfer that DAT to another, repeatedly for something like
>>8 or 10 generations and, each time, checking the intermediate
>>results by transferring back to hard disk and numerically
>>comparing.
>
>This test only deals with the WHAT question, not the WHEN question.
>
>>anyway Duncan challenged Grundman to repeat the experiment and/or
>>send him two tapes (original and dup) that Grundman felt sounded
>>different so that they could sample-by-sample compare them. i'll
>>bet Grundman didn't take him up on it.
>
>The point here is that we are long past the days when digital copies
>were considered exact if they were bit-for-bit accurate. We know that
>that's easy to do. What we are finding is that due to some rather
>poor equipment design, jitter from our playback devices can affect
^^^^^^^^
>what we hear. And it seems that jitter during recording affects the
^^^^^^^^^
>media to the point that the result is more jittery playback.
>
i thought the issue was digital-to-digital transfers, not recording
or playback. there is no dispute that when (say, during playback, as
in DAC) audio samples are output at unequally spaced times (which is
jitter), that that is an error. if it's bad enough, you can hear it.
in a digital-to-digital transfer, the 'WHENs' are never recorded on
the new tape, nor were they recorded on the old tape. if you
transfer both to the same hard disk (call them 'fileA' and 'fileB')
compare with some easily written software (or do the align, invert
one, and mix trick that was previously posted by someone else) that
confirms numerical identity, and playing both files, one at a time,
over the same _good_ gear, and if you say you hear a difference, i'd
say you'ld identify with the monster cable faction (i can't even
argue with those guys because we can't agree on any common basis of
fact or methods).
>The net result is that it seems that jitter can be cumulative or
>transferable, for all the wrong reasons.
>
true, if you were going though the analog and continuous-time domain
for the each transfer. then errors from all sources (including
jitter) will accumulate.
r b-j
c r e s c e n t e n g i n e e r i n g
rob...@audioheads.com
robert bristow-johnson
i know you guys are gonna pounce but...
In article <472vcv$1...@hustle.rahul.net>, Bill Llewellyn (thi...@rahul.net) writes:
>In article <472p5d$m...@relay2.uk.mdis.com>,
>Clive Backham <cl...@mx1.uk.mdis.com> wrote:
>>
>>: The net result is that it seems that jitter can be cumulative or
>>
>>somehow causes the resultant playback to have a different jitter
>>characteristic than the original tape of which it is a "clone". How can
>>this be? It strikes me that any digital copy should preserve whatever
>>jitter (if any) was formed at the initial A/D conversion step when
>>creating the original.
clive is correct, if the dig->dig copy was numerically faithful.
>> Gabe's choice of words seems to imply that he
>>knows the process by which the jitter burned into the copy is different
>>than that of the original. Please could someone explain.
>
>I'll try....
>
>Playing back one tape on one machine and recording it onto another tape on
>another machine does not result in verbatim duplication as when you
>overlay one magnetized mastering strip onto a recipient tape and add heat
>(one way of mass producing pre-recorded tapes) (different starting points
>and such notwithstanding). Exact bit positions are not preserved in
>machine-to-machine transfers. No, I'm not saying bits move into adjacent
>bit cells and create errors, I'm saying that each bit *will* reside in a
>slightly different position within its respective bit cell on the dubbed
>tape with respect to the original, and in playback this manifests itself
>as altered jitter characteristics. Why? Because the serial data stream of
>the tape A is fed through a retiming circuit (PLL) which standardizes the
>bit positions to a new clock (VCO) extracted from tape A's data stream.
>This new clock is uses to write the data onto tape B. This clock also does
>not follow tape A's jitter exactly, but smooths it in a low-pass filtering
>fashion.
>
> Tape A playback data -> PLL -> data buffer -> Tape B recording data
>
>The PLL reshapes the jitter, actually, in two ways: (a) it supresses HF
>phase noise but passes LF phase noise (HF/LF breakpoint depends on system
>design), and (b) it can add it's own jitter, the degree of which depending
>on the PLL's quality. Thus, tape B has (quite possibly entirely) different
>jitter characteristics than tape A.
>
but _so_ _what_? all of that jitter is _unused_ in the final
playback unless it's so bad that you _do_ lose bits or samples.
upon playback:
Tape B recording data -> reasonably big data buffer -> DAC --> output
^
|
high frequency DAC clock ---'
it's only the jitter of the clock applied to the DAC that will
cause the output samples to jitter. all of the jitter of the
samples going into the buffer (except for the jitter error
incurred during the original ADC) are forgotten about by the
time the data gets out of the buffer.
Stefan Heyer
>Stefan Heyer <he...@massive.aball.de> wrote:
>>Scott and Gabe (and probably others), why do you spend so much of your
>>time and energy on this ..ahem.. "debate" ?
>
>
>(deleted anecdote - although quite ineresting)
>
>There is big problem with the way the cheap digital stuff sounds. I
>see people getting rid of good sounding analogue gear in exchange for
>much worse sounding digital gear. Now, this sort of thing has gone on
>long before digital recording exists, and I thank the process for having
>got me a lot of great hand-me-down gear that was much better than the
>gear that replaced it. But nobody is going to fix the problem until
>they know that it's a problem, and unless it's fixed, I will have to
>listen to lousy-sounding records.
>
>And I don't _want_ to listen to lousy sound, or lousy performances for
>that matter.
>--scott
This thread started off with the question of digital transfers, which
using some mid-priced studio dat __in proper condition__ shouldn´t
cause too many audible problems (I never heard any). Of course, if
somebody uses inferior DAC´s, it´s another story. But that´s a point
almost everyone on this list will agree to anyway. So all this prolonged
discussion about jitter here and there seems a bit far out to me.
What worries me more are the procedures people use for their listening
tests. Everybody just tells you they "hear a difference" or even give
poetic descriptions of this difference. But what did they actually do?
I suspect they just muted two channels on their mixer and dropped in two
others with about the same gain and then decided there was a difference
(and this may even be one of the better designed "testing procedures"
of which we are just told the results). And many people simply rely on
"long experience" or "golden ears".
Quite frankly, everybody in the field of, say, biomedical or
psychological research would openly laugh about this or silently weep and
say nothing. But this is what half of the discussions in this list are
based upon.
Of course i agree with you in that there are problems with digital stuff.
And I appreciate it if people give their two cents about some equipment
they worked with - I have asked for such on this list myself.
But before I have to search through lengthy discussions of this sort i´d
rather hear from somebody who carried out a _proper_ listening test and
giving us a complete description of the procedures, as we get it in
decent scientific publications. This would be an acceptable basis and
motivation for threads like these.
Apart from that, as i replied to gabe before, my primary concern in my
post cited above was the _style_ of the discussion. If you go to great
lenghth about the opinions of someone who just SHOUTS in a self righteous
and somewhat confusing manner (remember how it all began?), what will a
newbie think when he politely asks a little question and gets 2 lines as
a reply or is completly overlooked?
Stefan
Stefan
Juha Kuusama
>>the issue of the bits or samples on DAT being recorded at jittered
>>times is dealt with by buffering the data from when it's pulled
>>off the DAT to when it's output to the DAC. any unequally spaced
>>times are forgotten about by the time data gets to the DAC.
>You have completely neglected the entire question of second- and
>third-order electrical interactions.
I have no trouble believing that if the buffer output clock, whether a
pll stabilised VC(X)O or a crystal, is running from the same power supply
as the circuitry clocking data into the buffer, the timing of the writes
have an effect to the phase of the output clock. Phase noise on an
oscillator spells jitter on the audio. Come to that matter, a low phase
noise oscillator need probably a power supply of its own...
Juha Kuusama
Sample Rate Systems Oy tel. + 358 31 3165 045
Kanslerinkatu 14 fax + 358 31 3165 046
33720 Tampere, Finland e-mail: Juha.K...@samplerate.fi
Chris Caudle
but _so_ _what_? all of that jitter is _unused_ in the final
playback unless it's so bad that you _do_ lose bits or samples.
upon playback:
Tape B recording data -> reasonably big data buffer -> DAC --> output
^
|
high frequency DAC clock ---'
What you are neglecting is the source of the high frequency DAC clock.
As Bill Llewellyn pointed out, one of the most common DAT decks in
use today, the Panasonic SV3700, does not use a clean reference
for that clock, but derives it from the data on the tape. Jitter on the
tape results in jittered clock (with a modified jitter spectrum, as Bill has
pointed out). In an ideal world, yeah, the data buffer would eliminate
all the jitter between the recording media and the output, but in the
world of cost constrained designs, and just plain lazy and cheap engineering,
apparently it doesn't always work as nicely as we would like.
Chris Caudle
cau...@bangate.compaq.com
Paul Braunbehrens
cau...@bangate.compaq.com (Chris Caudle) wrote:
-> rob...@audioheads.com (robert bristow-johnson) wrote:
-> but _so_ _what_? all of that jitter is _unused_ in the final
-> playback unless it's so bad that you _do_ lose bits or samples.
-> upon playback:
-> Tape B recording data -> reasonably big data buffer -> DAC --> output
-> ^
-> |
-> high frequency DAC clock ---'
->
->
-> What you are neglecting is the source of the high frequency DAC clock.
-> As Bill Llewellyn pointed out, one of the most common DAT decks in
-> use today, the Panasonic SV3700, does not use a clean reference
-> for that clock, but derives it from the data on the tape. Jitter on the
-> tape results in jittered clock (with a modified jitter spectrum, as Bill has
-> pointed out). In an ideal world, yeah, the data buffer would eliminate
-> all the jitter between the recording media and the output, but in the
-> world of cost constrained designs, and just plain lazy and cheap engineering,
-> apparently it doesn't always work as nicely as we would like.
->
->
-> Chris Caudle
-> cau...@bangate.compaq.com
I'm really glad this discussion went on, I have learned almost as much
from it as I have from the old infinite resolution debate. If I
understand things properly, then basically we don't have to worry too much
about jitter, even taking into account what Gabe has said.
If jitter is only a problem on poorly designed machines, then the final
product (CD or whatever) will play back nicely on good systems, and poorly
on bad systems (which will reclock to a stable clock and get rid of the
jitter). What else is new?
If this is simplistic, please enlighten me....
Cheers,
---------------------------------------------------
Baka...@bakalite.com (Paul Braunbehrens)
Administrator Daw-Mac Owner Bakalite Sound
http://www.bakalite.com ftp://ftp.bakalite.com
---------------------------------------------------
Jonathan Edelson
Juha Kuusama <Juha.K...@samplerate.fi> wrote:
>I have no trouble believing that if the buffer output clock, whether a
>pll stabilised VC(X)O or a crystal, is running from the same power supply
>as the circuitry clocking data into the buffer, the timing of the writes
>have an effect to the phase of the output clock. Phase noise on an
>oscillator spells jitter on the audio. Come to that matter, a low phase
>noise oscillator need probably a power supply of its own...
Yet another factor to consider is that if one were to use a 'kick-ass'
stable VCO (KASVCO), then one would be trading off one's ability to synch
quickly to incoming signals. One either then has the spectre of not
being able to accept data that a lower quality device has no problem with
(more correctly, no easily discernable problem), or one uses a buffering
scheme, and one has to deal with lags between the operation of the source
machine and the destination machine.
A machine with a 1MB buffer and absolutely _no_ synchronization to the
incoming clock source could function for quite a while without a buffer
over-run or under-run; at least for reasonable tolerance of the source
clock. However one would see things like 5 second delays between
stopping the source transport and flushing the buffer.
-Jon
--
win...@teleport.COM Public Access User --- Not affiliated with Teleport
Public Access UNIX and Internet at (503) 220-1016 (2400-14400, N81)
Scott Dorsey
>
>I'm really glad this discussion went on, I have learned almost as much
>from it as I have from the old infinite resolution debate. If I
>understand things properly, then basically we don't have to worry too much
>about jitter, even taking into account what Gabe has said.
>
>If jitter is only a problem on poorly designed machines, then the final
>product (CD or whatever) will play back nicely on good systems, and poorly
>on bad systems (which will reclock to a stable clock and get rid of the
>jitter). What else is new?
This is absoutely true! However, what is new is that most people don't
seem to realize just how bad their bad systems are.
Well, I suppose that's not all _that_ new....
Bill Llewellyn
Chris Caudle <cau...@bangate.compaq.com> wrote:
>rob...@audioheads.com (robert bristow-johnson) wrote:
>but _so_ _what_? all of that jitter is _unused_ in the final
>Tape B recording data -> reasonably big data buffer -> DAC --> output
> |
> high frequency DAC clock ---'
>
>
Hi, I'm your footnote reference. :) Let me be the first to try a little
egg on my face.... I was right and wrong in that observation (blush); the
3700, upon further digging in the documentation, uses a local, fixed clock
for DAC timing which is split from the playback PLL. I should have
realized this because the data playback PLL has to operate in
discontinuous bursts as the data stripes are read off the tape (block
segments) and loaded into the fifo, but the fifo output and the DAC must
have a continuous clock. That was the wrong part. (Write 100 times "I
will not....") I stand corrected. I'll have some ketchup with my shoe,
thanks.
The right part is this: What is used as a DAC clock is *still* a PLL
output; there's a synthesizing PLL (called a "digital PLL", which appears
to do 12x frequency scaling) feeding a parallelizer chip which feeds the
DAC section. I'm gonna get my scope and find out if this is where the
infameous jitter originates. If so, there may be hope for improvement with
a little cleanup work.
Now the big question. What mechanism might allow tape jitter get through
and effect the audible quality of the playback and produce the difference
between original and copy the original poster spoke of? (I'm not through
digging through that 3700 manual, yet.)
Hey, isn't there a 3700 serviceperson on r.a.p somewhere who can just
blurt it out? A Panasonic tech?
--
Bill
Monte P McGuire
Bill Llewellyn <thi...@rahul.net> wrote:
>
>Here's an interesting thought, for those real DSP people out there to
>think about. In a DAT machine like the 3700, the playback signal is 4x
>oversampled (fed to a digital filter being clocked at 4x the sample rate)
>and the missing pieces are "filled in" by the filter. This is fed to a MASH
>noise shaper circuit for dithering. The result is pseusdo-18 bit audio.
>This, of course, eases the burden on the subsequent analog low-pass
>filter (brick wall not needed; sheet-rock, maybe).
>
>My question regards the MASH circuit which performs a form of noise
>dithering. Given it's a digital chip, I'd presume it uses a psuedo-
>random sequence generator as its source of noise.
>Any psuedo-random sequence has a starting/looping point which
>I'd assume is unrelated to the digital audio signal being converted
>to analog. Thus it would seem that repeated playings of a DAT would yield
>different relationships between the "phase" of the psuedo-random noise
>source and the program material. Might the human ear perceive this?
>(This *might* even be a factor in the original poster's observations
>about audible playback differences.)
There is no dither added to playback by any D/A. All you need to do
upsample the audio, filter it to the original bandwidth and send the
now wider width data to the DAC. So while it's an interesting
possibility, it couldn't affect playback.
BTW: Isn't the MASH chip the Panasonic single bit A/D? They use Burr
Brown ladder style DAC chips (PCM56) in the 3700 if I remember
correctly.
Chris Caudle
>There is no dither added to playback by any D/A. All you need to do
>upsample the audio, filter it to the original bandwidth and send the
>now wider width data to the DAC. So while it's an interesting
>possibility, it couldn't affect playback.
I'll dig out the data sheet I have at home, but I believe the NPC
oversampling filters have a 24 bit accumulator, and allow
truncation to 16, 18, or 20 bits, with or without dither.
Unfortunately, the data sheet gives no information on how the
dithering is implemented.
Chris Caudle
cau...@bangate.compaq.com
Bill Llewellyn
>
>But don't forget: We can know UNAMBIGUOUSLY whether our data is intact
>or not. In particular, we can always know if there is any interpolation
>going on. In my testing I have heard differences under blind listening
>conditions from two sources containing identical data, when it was known
>without ambiguity that there was no interpolation going on.
Here's an interesting thought, for those real DSP people out there to
think about. In a DAT machine like the 3700, the playback signal is 4x
oversampled (fed to a digital filter being clocked at 4x the sample rate)
and the missing pieces are "filled in" by the filter. This is fed to a MASH
noise shaper circuit for dithering. The result is pseusdo-18 bit audio.
This, of course, eases the burden on the subsequent analog low-pass
filter (brick wall not needed; sheet-rock, maybe).
My question regards the MASH circuit which performs a form of noise
dithering. Given it's a digital chip, I'd presume it uses a psuedo-
random sequence generator as its source of noise.
Any psuedo-random sequence has a starting/looping point which
I'd assume is unrelated to the digital audio signal being converted
to analog. Thus it would seem that repeated playings of a DAT would yield
different relationships between the "phase" of the psuedo-random noise
source and the program material. Might the human ear perceive this?
(This *might* even be a factor in the original poster's observations
about audible playback differences.)
--
Bill
robert bristow-johnson
In article <474h0j$c...@panix.com>, Gabe M. Wiener (ga...@panix.com) writes:
>In article <8...@audioheads.com>,
>robert bristow-johnson <rob...@audioheads.com> wrote:
>>'WHEN' (i s'pose you mean jitter, because i'm not prepared to deal
>>with the possibility that a recording sounds better or worse today
>>than it sounded yesterday)
>
>
no, gabe. it was a feeble attempt at levity. the difference between my
'patronizing' and yours was that yours is clearly IMHO a putdown,
undervaluing what someone else says [allusions to the game-show host
or judge (with final authority on truth or fact) buzzing the hapless
contestant as he guesses for an answer]. who was i putting down? i wasn't
guessing for an answer, i still stand by what was said in the context of the
whole post and the main issue of the thread. none of us can presume to be
final authorities in issues of audio and all can possibly learn from others
in the newsgroup. we can also act as if we can learn from others in the
newsgroup.
...
>>is an issue of the quality or
>>performance of the recording and playback gear. 'WHEN' is not
>>a quantity recorded on digital audio recordings
>
>No, it isn't a quantity recorded as an attribute, but there is no
>reason to doubt that a physical attribute of a disc (be it geometric,
>static, whatever) might not change the behavior of the playback device,
>even though the data is identical.
>
>There is, in fact, very strong evidence to suggest that such phenomena
>do in fact exist, and that in certain cases and on certain equipment,
>they can have a most demonstrable effect on audible playback.
>
>>the issue of the bits or samples on DAT being recorded at jittered
>>times is dealt with by buffering the data from when it's pulled
>>off the DAT to when it's output to the DAC. any unequally spaced
>>times are forgotten about by the time data gets to the DAC.
>
>You have completely neglected the entire question of second- and
>third-order electrical interactions.
>
i have deliberately decoupled the issue of dig->dig transfer to that of
dig->analog playback. these '2nd and 3rd order electrical interactions'
(a very generic term that can mean almost anything) are issues
of playback (or recording).
...
>Well, this opens a whole new area of questioning. Even if the
>transport is flushing all the data through a FIFO buffer, and
>pulling it off at regular intervals with a PLL circuit, who is to
>say that the stability of the clock as transmitted thereafter
>(at any point in the chain) isn't affected by, for instance, the
>changing loads on the power supply?
>
at least two really freakin' good voltage regulators isolating
the transport from the DAC and clock, and DAC and clock circuitry
designed to be reasonably insensitive to small P.S. variations
around the normal P.S. voltage. nonetheless, it's an issue of
playback quality not of dig->dig transfer.
the issue here is whether numerically accurate digital-to-digital copies
contain errors or differences that can be heard when played through the
identical and well designed piece of gear. one thing i'm learning is that
what should normally be considered (by me, at least) to be a well
designed pro DAT player is not ubiquitous in the industry. i dunno if the
panasonic SV3700 or whatever model of DAT derives its DAC clock from
the tape data rate (it should be the other way around) or not, but if it or
another DAT does, i wouldn't call that 'well designed'. the data applied
to the DAC should clocked by a stable and low jitter clock and the tape
(or CD) speed carefully and minutely adjusted to keep the data buffer in
between the medium pick-up and DAC about half full. there's no reason to
derive the DAC clock from the data rate off the tape but i won't say that no
product does that, it just seems silly that they would design a recorder/player
using any medium to do that. even if one does, it's not an issue of dig->dig
transfer accuracy but rather an issue of appropriate playback technology.
gabe says that these jitter errors (during dig->dig transfers) accumulate
and can be heard upon playback and i'm saying that if played back with
'appropriate playback technology' these jitter errors are totally forgotten
about and what is left is the original (if the transfer was numerically
accurate) numerical sample data output at equally spaced times with jitter
determined only by the DAC clock which had better be stable and
independently (from the tape) generated.
if push comes to shove, the 'appropriate playback technology' can be to
transfer the DAT recording of both copies (that gabe says sound different
but are numerically identical) to hard disk and played out from there. if
the two resulting sound files are numerically identical (after aligning and
trimming) i think even gabe concedes that you can't tell them apart. if
they aren't numerically identical for whatever reason (perhaps that the
dig->dig transfers had such awful timing errors that bits were lost and
error concealment had to kick in), i wouldn't claim the transfer was
numerically or sonically faithful. otherwise, there is no 'contamination'
(in the same sense of generations of noise as in analog duping) that
remains after the dig->dig transfer.
now if you don't like the extreme case of 'appropriate playback technology'
(transfering to and playback out of HD) just think of it as an extremely
long delay buffer. there is no reason (despite gabe's list of internal
interactions of supply voltage, DAC clock, and tape transport servo) a
DAT player could not do the same thing (with a lot less delay in its
buffer) if designed to. nonetheless, even in the case of the poorly
designed DAT player (where the output DAC clock is derived from the tape
data as suggested by some), that does not mean the dig-to-dig transfer was
not sonically faithful although it was numerically faithful albeit
_slightly_ jittered. it just means you need a better DAT player.
so i still stand by this _very_ conservative (and slightly updated, not
for content or meaning but for clarity) axiom: for two digital recordings
(no particular media is specified) to sound different in the same context
(using decent quality playback with stable and independent DAC clock),
there must be a numerical difference between the two. if gabe wants to
refute that, it's fine. i'd guess we might discuss methods of blind
testing (it would be pretty hard to double blind test the identical CD
example cited). loser gets to pay the cost of the test.
Scott Dorsey
>Can anybody comment on how specific pieces of equipment stack up vis-a-vis
>this thread? Obviously the SV3700 is not much in favor, can anyone name
>names that are also problematic or exemplary? I must say I have not heard
>problems when cloning SPDIF from my Sony DTC1000 to Tascam DA30.
As I have said before, if you have an outboard DAC that reclocks, it
shouldn't matter a bit what kind of jitter you have got. So you should
be asking the question about what outboard DACs solve or exaggerate this
problem, not about the equipment which precedes it in the signal path.
The Panasonic has so much phase error that some equipment just plain won't
lock up to it, and you get silence instead of music. It is also picky about
the kind of data that the input will accept. This is not a jitter issue.
This is just a bad interface design issue. Whether you believe that
jitter is audible is one question that is worthy of argument here, and
seperate from the easily proven fact that if you plug unit A into unit B
you don't get any music. The latter is much easier to trace and verify.
robert bristow-johnson
In article <DHBLs...@twisto.eng.hou.compaq.com>, Chris Caudle (cau...@bangate.compaq.com) writes:
>rob...@audioheads.com (robert bristow-johnson) wrote:
>but _so_ _what_? all of that jitter is _unused_ in the final
>playback unless it's so bad that you _do_ lose bits or samples.
>upon playback:
>Tape B recording data -> reasonably big data buffer -> DAC --> output
> ^
> |
> high frequency DAC clock ---'
>
>
>What you are neglecting is the source of the high frequency DAC clock.
it's not neglect but an assumption of reasonableness in the
design of the thing. well, you know what the say about the
word, 'ass_u_me'.
>As Bill Llewellyn pointed out, one of the most common DAT decks in
>use today, the Panasonic SV3700, does not use a clean reference
>for that clock, but derives it from the data on the tape.
that is just inexcusable. there's no need or technical reason for
it. what, then, ultimately determines the tape speed? if done right,
the tape speed is determined by how full the data buffer is. if
the buffer is more empty than full, the data rate and tape speed is
increased, if more full than empty, the data rate and tape speed is
decreased. on a CD, the disk spins faster for inner tracks than
outer tracks. i'm sure the 'constant' criteria for determining
disk rotational speed is the required data rate. i can't imagine
why it would have to be different for DAT.
Mike Rivers
> Yet another factor to consider is that if one were to use a 'kick-ass'
> stable VCO (KASVCO), then one would be trading off one's ability to synch
> quickly to incoming signals.
You probably think you're kidding, but someone reported seeing a
44.1/48 kHz reference that locks up to an atomic clock somewhere, with
the idea being that it would be your standard digital clock reference.
It's clear that it's sufficiently accurate to get you to town in time
for your 2:30 dentist appointment, but I wonder if it's short term (like
within a fraction of one cycle) stability is sufficient for a 'no
jitter' reference.
George Ludwig
>so i still stand by this _very_ conservative (and slightly updated, not
>for content or meaning but for clarity) axiom: for two digital recordings
>(no particular media is specified) to sound different in the same context
>(using decent quality playback with stable and independent DAC clock),
>there must be a numerical difference between the two. if gabe wants to
>refute that, it's fine. i'd guess we might discuss methods of blind
>testing (it would be pretty hard to double blind test the identical CD
>example cited). loser gets to pay the cost of the test.
But part of Gabe's asserion was that in the CD format, you can have 2
numerically identical disks with an ever-so-slightly differnt physical
formatting. These subtle differences cause what Gabe calls "second and third
order electrical interference", meaning that the clock gets a little screwey
'cause the transport has to work a little harder to read a less-than-optimal
physical format which causes fluctuations in the juice feeding the clock. The
ever-so-slight difference in physical formatting doesn't affect (seemingly)
playback from hard-disk. Personally, I wouldn't know 'cause my AD/DA box is
external anyway.
I agree that in a well-engineered professional system, this shouldn't be an
issue. But then, I'm an idealist.
George
Michael Johnson
D-D transfer is probably exact. If anyone would like a demonstration, I
would be glad to give you one. I invite you here to my studio where we
will play a CD of your choice as reference onto my A drive, bank copy it
to my B drive, and then place them both in a sequence and switch between
them using the same DAC on the console and listening through the same
B-chain. If you actually hear a difference, the sixties were really good
to you. Bruce Swedien did experience the phenomenon you are talking about
once, but that was on an old less than perfect DAW after 10, count them
*10*, disk copies. Just try to take your favorite application on your
computer and copy it 10 times and see if it works right. The point is
that we are in an imperfect world, and somewhere eventually, a bit is
going to get changed because of a read error.
Look for a problem where it exists...wild goose chases are for the birds.
Just my three cents (inflation you know).
Please, no flaming. My opinions are uniquely mine and I don't expect
anyone to agree with them.
kaiser
--
kai...@qnet.com
We live together as rational human beings, or die together as fools. -Dr. Martin Luther King, Jr.
Gabe M. Wiener
Brandon Mathew <bra...@core.rose.hp.com> wrote:
>I think the reason it's not a problem from hard disk is that the system
>is designed differently.
Well, I've asserted that I've never encountered this problem when playing
back from hard disk, and your technical description seems pretty accurate
as to why HDs get around this.
But this isn't to say that there might not exist a hard disk system that
_does_ exhibit this sort of phenomenon. I posted a rather elaborate set
of circumstances under which a hard drive might suffer the same effects,
but I've never known it to happen.
>Isn't there anyone in this forum who has actually designed CD
>transports who can tell us how it is actually done?
Bob Stuart, you out there?
Gabe M. Wiener
>You probably think you're kidding, but someone reported seeing a
>44.1/48 kHz reference that locks up to an atomic clock somewhere, with
>the idea being that it would be your standard digital clock reference.
I saw this unit at AES. It is rated to 44.1000000 kHz. That's great for
long-term stability, but I want to know its short-term accuracy.
I also want to know what kind of cables you use so as not to induce
any jitter during the transmission.
At $12,000, I think I'll let someone else find out, thanks.
Michal Jurewicz
MASH is a digital filter + a delta-sigma modulator which does a simple noise
shaping- there is no any pseudo random noise generator there.
However- cheap MASH DACs are very sensitive to jitter (there is a math.
theory for it) much more than multibit DACs.
Michal at Mytek - 20 bit digital audio- http://www.ios.com/~mytek
mich...@musicbiz.com
This is a collection of comments about the whole thread, or at least
what I read of the almost 100 pages of it. (Is anybody still reading?)
I do hear in many cases differences between generations of digital
recordings, and I admit that this is not a scientific based observation.
The most consistant one is between the Master tape and the CD cut from
it, but here we already decided to condemn the Sony 1630, even though
its converters do not take part in the CD mastering transfer.
To the "Scientific\Statistical" community, all I have to say is that I
learnd years ago not to dismiss other people aural observations, even
if it will take time to come up with an explanation and or proof (the
case of absolute polarity comes into mind).
In digital transfer many things come into act on the side of Murphy.
Dither and the obnoxious Panasonic were already discussed, but any level
2 or higher of error correction, which on its own might be forgiven, is
now interpolatedwith at best 1/2 bit certainty, which translate to
A)inaccuracy.
B)"recording" of interpolated data with no dithering and no control
other then some interpolated clock in many cases.
Some years ago, I tried to edit on a Digidesign Sound-Tools (An early
one, 1988-89)end was very unhappy with the results. Some
experimentation showed that just loading a tape to disk, and dumping
back to tape was enough to change the sound, and a call to Digidesign
got the reply that there is no audible degradation, (later corrected to
"detectable degradation").
After a while they admitter a "little" mistake in their algorithm,
namely that on the negative side,they areone quantization level of, but
no one can hear it.
Well they lost a customer,(me and some NPR stations I was working with)
just because of that last statement, and I believe that they corrected
that little mitake which translate to wrong Zero crossing.
It seems that in every stage of digital transfer we might have some
inadvertant "Processing taking place,which translate to some
interpolation,bytes over time or lsb's, and we do not bother dithering
or listenning because being digital it should be flawless.(I once had a
misshapp that forced me to use a cassette as the only recorder, I
coppied it to DAT, submitted it, nobody asked anything or criticized.
It was broadcasted nationwide, but it was supposedly digital).
sorry for the length of rambling but I had to take B.L. on his
misspelling chllange.
Micha Schattner
Recording Services
--
The Music Biz BBS "Where Music People Connect"
Unlimited Internet Email * Usenet Music Newsgroups * Music Networking
(617) 277-1996 All lines 14.4k
Jonathan Edelson
Brandon Mathew <bra...@core.rose.hp.com> wrote:
>I think the reason it's not a problem from hard disk is that the system
>worry about latency of data from disk, so you pre-read the data into
>buffers and clock it out at a steady rate. On a CD players and DATs, I
>suspect that they simply get the bits as they fly by and don't worry if
>they are really that accurate.
On CD players and on DATs, the data that is read off of the media is of
necessity buffered because of the various coding techniques that are used
for the error correction systems. These buffers are pretty minimal.
So, _hopefully_, the data will be read from the media, and then clocked
out of the buffer at a constant rate. Presumably physical differences
between media which encode the same data can alter the clock used to
time the data leaving the buffer.
WRT error correction: CDs and DATs use extensive foward error
correction, meaning that the data is stored with lots of redundancy, so
that after the data is read from the media any bit errors can be detected
and corrected. Computer storage systems based upon these audio media do
several things to reduce the error rate: they add even more redundancy,
they will _retry_ reads if an uncorrectable error is detected, and if
they can't get a correction, then they will report the error.
> I say that since the data is coming off
>the media in a sequential fassion; that can't be guaranteed with a hard
>disk. It's purely speculation, but that's how I like to think about it
>anyway. Isn't there anyone in this forum who has actually designed CD
>transports who can tell us how it is actually done?
With data coming off the hard disk, jitter could be introduced in the
same fashion as above; the disk head seeking could somehow influence the
clock being used for output. A computer is such a noisy environment,
however, that I would expect there to be less correlation between the
location of files and jitter on the output clock.
I don't doubt that there can be transmission of jitter between recording
links. However, presuming accurate transcription of the bits, I figure
that there will be some point were 'new' jitter being introduced into the
data stream will totally mask 'old' jitter. Eg one makes a master
recording. One then makes two copies. On a particular piece of
equipment once can tell copy A from copy B. On now makes additional
copies, A' and B', and one can still tell A' from B'. I would bet that
in a blinded test, one could tell A'''''' from B''''''; but given A''''''
and B'''''' and A and B, I would bet that it would be impossible to
determine which of generation '''''' decended from which of the first
generation.
Bill Llewellyn
>sorry for the length of rambling but I had to take B.L. on his
>misspelling chllange.
Doon't get me starded.
--
Bill
robert bristow-johnson
In article <479o98$1d...@ds2.acs.ucalgary.ca>, Brad A. Yingst (bayi...@freenet.calgary.ab.ca) writes:
>In article <8...@audioheads.com>,
>robert bristow-johnson <rob...@audioheads.com> wrote:
>>outer tracks. i'm sure the 'constant' criteria for determining
>>disk rotational speed is the required data rate. i can't imagine
>>why it would have to be different for DAT.
>>
>>
>I am no audio expert but,this sounds like mith to me last time i checked
>a cd player it had a simple dc motor"constant voltage"Wouldn't changing
>speeds of a player need a stepper motor for acurracy.
no, a DC motor with a DC servo-amp driving it can do different
speeds. i would think a stepper motor would be better (a servo
control system that does frequency adjustments on the pulse signal
going into a stepper seems to me to be cheaper and easier and more
accurate than a DC DAC and DC amp), but who knows?
>And don't tape
>speeds change with the size of the reel(a sort of gear system)I would be
>real interested in opinions/facts about this one.Or am i misinterpreting
>speed to be distanced traveled IE.the revolutions stay the same the
>distance travelled changes.
i'm pretty sure the linear tape speed is constant and determined by
the capstan speed and the rotational reel speed changes. the
capstan speed of a DAT _should_ be controlled by how full or empty
the data buffer (between the tape pickup heads and the DAC output)
is.
>I could see tape velocity beeing consisten but
>cd velocity would be a little different wouldn't it ??????
>
i remember reading it in some trade rag or maybe it was in
watkinson's or pohlmann's book(s). anyway, try this experiment:
1. get a cheap little sony DISKman or whatever it's called.
2. open it up, pop in a cd with multiple tracks. don't
close it.
3. using a wooded match stick or similar, defeat the little
safety interlock in the lower left corner by gently
pushing the stick against the teeny-weeny microswitch
that the plastic tag poking out of the DISKman lid would
hit if you closed the lid like you're supposed to. i
dunno if there is a laser vision danger or not so i'm
disclaiming responsibility. do it at your own risk.
wear sunglasses. i dunno.
4. hit PLAY and notice that the laser lens transport (or
whatever they call the damn thing) moves visibly to the
inner track. you can see a little of it through the
transparent hub of the CD. this means track 1 is the
innermost track. (i remember reading that also. doesn't
really matter.)
5. note the rotational speed of the spinning disk. hit
the track advance button 8 (or N-1) times to get to the
9th (or Nth or last) music track. note the rotational
speed of the disk (it will be be slower) and that the
laser lens has moved away from the inner track.
i didn't design the damn thing, but i would bet:
1. that the pit density of the inner and outer tracks are
roughly constant.
2. that the data is clocked into the DAC by a reasonably
stable and independent (as well as it's designed) clock
that is not derived from the data stream from the CD.
3. that the rotational speed of the CD motor is determined
first and roughly by which track number the pickup lens
is on and secondly and minutely by how full the data
buffer between pickup and DAC is. the speed increases
slightly if the buffer is too empty and decreases
slightly if it's too full.
i just got e-mail from someone who says it's likely the same way for
the SV3700 DAT (i dunno, i don't own any DAT nor have reviewed any
technical info on one). i'll leave it up to him to post it if he
wants to.
finally, i'm leaving this thread alone (usenet cheers... , i
generally 'lurk' on this newsgroup and am a little more active on
comp.dsp). i've said what i intended to: that the issue of _small_
amounts of jitter is (or should be) decoupled from the issue of
dig->dig duping. as long as the copy is numerically correct (the
numbers are the same and in the same order) and there aren't gross
timing errors ('jitter' is not a strong enough term for it) that
causes bits to be lost and error concealment to kick in, the copy
should sound the same. if it does not, the issue to bitch about is
not duplication but DAC conversion and playback.
Chris Caudle
>We use Ultra Analog AES20 in our DDAC20. It is the best device we found so far.
I believe this uses a Crystal Semiconductor Corp. receiver, followed by a
LC VCO, if the information I have heard is correct.
>What is good about it is that it not only stabilizes the AES/EBU clock,
>you can actually apply a clean clock right to the DAC chip which allows you
>to bypass all source of jitter including these of the DAC input circuit.
>Michal at Mytek http://www.ios.com/~mytek
Not to change subjects mid-thread, but how is this accomplished?
Wouldn't you have to know the latency of whatever processing
came after the receiver (oversampling filter, reverb, eq, or compression
dsp, etc) to make sure the word clock that you were sending to the
DAC input matched the data it was receiving?
Michal, can you give more information on the details of the Mytek
implementation?
Chris Caudle
cau...@bangate.compaq.com