RE: [linux-audio-dev] Final Scratch, custom kernel?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] Final Scratch, custom kernel?
From: Pieter Palmers (pieter.palmers_AT_student.kuleuven.ac.be)
Date: Wed Oct 09 2002 - 01:00:55 EEST


Hi all,
it's been some time since my last post but probably you all know the
problem(s) with time...

Reading the Final Scratch thread, I remembered a similar discussion some
months ago. I posted the following scheme ( see below) as a proposal for
such a system. The main issues you have here are very similar to the issues
present in Telecommunication equipement. The scheme uses some telecom
concepts, and probably could be improved even more. Using the right coding
techniques, it's possible to retrieve data from a system with SNR even lower
than 9dB... Keeping in mind that for example an AM radio broadcast has a SNR
of > 60dB, it should be clear that a record provides plenty of data
capability.
The issue of pitch detection resides, but can be addressed too.

The main thing I'm trying to say here is that this problem is very like to
the problems in digital telecommunications. And they have solved them. So
why not use these techniques? Who's to say that QPSK or so cannot be used on
a record? I don't have the time right now, but with a little help of someone
with telecom knowledge, it should be possible to create a very good scheme.
This thread mentiones the use of a saw waveform, with success... but there
are better options, that will result in better performance.

I'm aware that all of this is a little vague... use it if you want. or don't
use it.

Pieter

PS: I'm more of an audio guy than a telecom guy, believe me. The only
problem is that
the people that teach my classes are telecom guys. And telecom is (or was) a
big
market, so who's to blame them...

and now for the original post:
(a little telecom knowledge doesn't hurt)
(26-jan-2002)
----------------------------------------------------------------------------
------------
The way Stanton probably syncs (as they support 'needle dropping') is to
have some time code on the LP, instead of a sawtooth, which is ok for
sync'ing and direction, but doesnt provide 'absolute' time info.
It would be better to use a passband digital modulation. That way you can
embed some kind of 'timer' in the LP.

For example: use a 1000Hz carrier with a AM/FM modulated differential NRZ
code. You can then put e.g. every 10ms a number on the disc using the
coding. That way, if you decode the modulated signal, you perfectly know
where on the disc you are.

Let me do the math (so I see if this is possible):
Let's say you want a dub-plate of 10min=60000*10ms.
So if we use a 16bit number, we have 65536 numbers=+/-11mins.

If you use a carrier, you can extract the pitch change from the
carrier frequency (you are already doing this, I presume). If you
use AM modulation, this is very easy.

Assume Amplitude Modulation, On-Off Keying.
The bitrate of the signal would then be 16bit/10ms=1600bps, so the bandwidth
of the modulated signal is 3200Hz. This means that we would have to shift
the carrier to > 4000Hz to keep things easy. Let's say 5000Hz.

As the carrier period = 1/5000Hz, the maximal pitch resolution obtainable
would be 0.2ms, but that won't happen due to the PC latency. If you would
extract pitch from 10 carrier periods, you would have a 2ms minimal delay.

As for the binary 'timecode', let's assume we need 5 numbers to make a
descision about the correct position (e.g. 5 consecutive numbers needed to
make sure the software doesn't get confused when there is a scratch or so)

(5nrs*16bit/nr)/1600bps=0.05s=50ms. I would like to meet the DJ that can
drop his needle with a resolution of 50ms.

To further enhance the system, one could use a more efficient modulation,
like using raised cosine pulses instead of the block pulses I made these
calculations with. You could also use an error correction code, e.g.
Reed-Solomon like used on CD's. etc...

This might be a little technical, but I just wanted to explain how I think
they did it. And the techniques used are not that new... these are the most
simple digital communication techniques. A 2400baud modem uses more
sophisticated
techniques. The difficulty is applying digital communication theory to a
recorded medium...
They are actually using the LP as a sort of harddisk, the only difference
being that it can't contain a lot of data:
2^16 nrs * 16bit/nr / (8bit per byte) = 131072 bytes (131k)
but you can change the plate speed.

I see no reason why this system wouldn't work (when enhanced to tolerate
dust etc). The detection techniques are well documenten in communications
literature (PLL, coherent detection, etc). It's like said before (in the EVO
thread):
The creativity lies in applying know techniques to a new domain.

Anyway, I'd love any feedback on this, I instanly made this up, so I
probably
missed some major things...

cu,

Pieter
----------------------------------------------------------------------------
-----------------------


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Oct 09 2002 - 06:58:30 EEST