Decoding timecoded vinyl in MAX/MSP with a graphical frontend in flash. On the timecoded record, there’s a sinusoidal signal with a phase difference of 90 degrees between the left and right channel. When plotting the left signal against the right in an x-y plot, it will draw a circle with a radius corresponding to the amplitude of the input and a angular frequency that is a measure for the rotation speed of the record. If, for example by bad pre-amplification or wiring or a wrong balance setting, one channel is louder the other the circle will become an oval, resulting in an angular frequency that is not constant. To compensate for this, The right channel will be scaled to be just as loud on average.

fucking nice
At top-left of the patch, the signal is sent to the scaler, and then filtered to remove the high frequencies that i will discuss later on. Afterwards, the cartopol~ object transforms the signal to polar coordinates. In fact the speed of the record is now already calculated, but we need to transform it in a usable signal. In the leftmost oscilloscope in the patch, the amplitude of the signal is displayed. If it is lower than a certain threshold, we can assume that the records is not spinning, or the needle is off the record. In this case the calculated tempo will be set to zero. In the other case we can get the angular frequency by taking the time derivative of the angle. Since the audio input is sampled at a constant frequency, the delta~ object takes care of this. To get rid of the jump of 2pi after each cycle, i do not count values above 3. The left and middle oscilloscope of the group of three show the angle and angular velocity respectively. The calculated velocity is still quite unstable. The average~ object takes the moving average over a preset number of samples, removing the audible deviations in velocity. Finally, the velocity is scaled by -0.1935, so match the 0% position of the pitch slider to a playback speed of 1.
The derived tempo controls a groove~ object that plays a selected audio file at the desired tempo. The object has three outputs. Two audio, leading to the output of the soundcard and one that indicates the playback position with a value between 0 and 1.
Because the drawn waveform appears on the screen half a rotation earlier than it is played (or later, when the record is playing backwards), we need a wave~ object to retrieve the audio signal at that position. From that signal the peak values are measured, and passed to the flash player. From the position the angle of the record is also calculated, so the flash player is able to rotate the complete track waveform in such a way that the playback position is always on the bottom right (where the needle is). The angle and peak level are encoded and sent to the flash player using the flashserver object.

waveform
The record also encodes the absolute position of the needle. The records is split into segments, each with a distinct timecode. The total number of segments is chosen in such a way that each rotation has about 100 segments. In each segment the timecode is encoded by roughly 20 sub oscillators that digitally represent the position on the record. The amplitude of the sub oscillators is much smaller than that of the pilot tone (the one used to calculate the tempo), and besides they are also filtered out by the lowpass filter, so they will not influence the velocity calculations.
The problem for now is that i do not know the frequencies of the sub oscillators, nor the decoding scheme to go from a pattern of active oscillators to a time position. The first one is not very difficult to yield i think, just record the entire record, Fourier transform it, and if everything goes well, about 20 peaks will appear in the spectrum, giving away the positions of the sub oscillators. The decrypting of the position will be more difficult, because unlimited decryption algorithms are possible. The most obvious is of course the one where each oscillator represents one binary digit of a huge counter, directly indicating the position on the record. But i don’t expect it to be that simple. The bits will probably be scrambled, and there might be some error detection. Assuming a 45 rpm record with 100 segments per rotation you can encode 14.5 minutes in 16 bits. The exact number of suboscillators is not defined in the patent, so it can also be slightly above twenty. In conclusion: there is plenty of room left for error detection signals, and for special commands that are sometimes encoded of separate grooves on the record (skip to next/previous track for example).
Started in August 2009.
