kblsalat
dänzen!
Semesterferien, Langeweile, hier also der versprochene Thread mit bunten Bildern 
Allen, die nicht wissen, was ein Timecode überhaupt ist, empfehle ich, die Suchfunktion zu benutzen. So, Erklärung anhand der SSL Timecode-CD in drei Schritten:
1. Auswertung der Geschwindigkeit der Platte/CD:
Wie man im Bild erkennen kann, handelt es sich bei dem Timecode-Signal um eine Schwingung mit gleichbleibender Frequenz. Bei SSL beträgt die Frequenz dieses Signals 1000 Hz - pitcht man nun 1% hoch, hat das Signal eine Frequenz von 1010 Hz, pitcht man 0,1% runter, ist die Frequenz 990 Hz. Anhand der Frequenz und der Samplerate lässt sich also relativ einfach der Pitch-Wert errechnen.
Die Frequenz errechnet sich, indem man die Anzahl von "Zero Crossings" (anz) in einem Datenblock zählt, darauf achtet, dass anz modulo 2 = 0 ist (so werden nur ganze Zyklen berücksichtigt), dann anz durch 2 teilt, und diesen Wert wiederum durch die Länge des Datenblocks vom ersten zum letzten Zero Crossings in Sekunden (Anzahl Bytes / Anzahl Kanäle / Samplerate) teilt.
Das Problem hierbei ist, dass es sich um gesamplete Daten handelt. Die Nullpunkte findet man also nicht, indem man überprüft, an welchen Stellen der Wert eines Samples 0 ist - denn die Nullpunkte liegen meist zwischen zwei Samples. Somit ist diese Art der Frequenzmessung nicht besonders genau (für DJ-Zwecke aber wohl ausreichend).
2. Auswertung der Drehrichtung:
Wie man im Bild erkennt, sind der linke und rechte Kanal nicht genau gleich. Sie enthalten scheinbar zwar die selben Daten, sind jedoch in der Zeit verschoben.
Das macht auch Sinn, denn so lässt sich die Drehrichtung ermitteln. Liegen die "Peaks" des rechten Kanals ein gewisses Stück vor denen des linken (rote Linie), läuft die Platte vorwärts. Andernfalls wird gerade rückwärts gedreht.
Das ganze nennt sich Phasenverschiebung, die beträgt im Falle von SSL ca 90°. Hier ist die Samplerate kein Problem, da man im Grunde nur feststellen muss, wo die Position eines Peaks im rechten Kanal (posR) zwischen zwei Peaks im linken Kanal (posL1, posL2) liegt. Gilt posL1 - posR > (posL2 - posL1) / 2, läuft die Platte vorwärts, andernfalls rückwärts. Das würde theoretisch sogar mit einer Samplerate von 5 Samples pro Zyklus funktionieren.
3. Needle Drops/Cueing:
Auch wenn die Funktionen aus 1 und 2 eigentlich schon ausreichen, um ein DVS zu bedienen (sog. Relative Mode), ist es doch wünschenswert, die Nadel wie bei "echtem Vinyl" irgendwo auf der Timecode-Platte abzusetzen und direkt zur entsprechenden Stelle in der MP3 zu springen. Bei SSL scheinen die dafür benötigten "Timestamps" binär in der Lautstärke des Signals kodiert zu sein:
Wer in der Schule aufgepasst hat weiß, dass Zahlen in binärer Darstellung eine Kombination aus 1en und 0en sind. Dem aufmerksamen Leser stellt sich nun die Frage, woher SSL wissen will, wo das Ende und der Start einer solchen Zahl sein soll. Deshalb schauen wir einmal genauer hin:
Es gibt nicht nur hohe und niedrige Peaks, sondern eher hoch-hohe, hoch-niedrige, niedrig-hohe und niedrig-niedrige. Die hab' ich einfach mal a, b, c und d genannt, sonst kriegt man ja 'nen Knoten im Kopf.
Wenn man genauer hinschaut, sieht man also, dass die Signale auf L und R nicht nur Phasenverschoben sondern auch nicht 100% identisch sind. Ich gehe davon aus, dass diese Unterschiede dazu dienen, den Start, das Ende, etc, eines Timestamps aufzuzeigen. Das System dahinter konnte ich aber auch nach viel probieren und rumrechnen nicht "knacken", ich denke mal, das ist auch so von Serato gewollt. Falls da jemand mehr weiß als ich, kann er mich ja gerne aufklären
So, damit habt ihr dann auch die Erklärung, warum Timecode-Vinyl nach längerer Zeit nicht mehr richtig im Absolute Mode, dafür aber noch praktisch tadellos im Relative Mode funktioniert. Cue Burns, Kratzer, etc, haben einen großen Einfluss auf das sehr sensible Timestamp-System, da nur 1 Wert "kaputt" sein muss, um das ganze System zum Skippen/wilden Rumspringen zu bringen. Der Relative Mode funktioniert dann aber immer noch, da 1 falscher Wert wenig bis gar keinen Einfluss auf die errechnete Frequenz hat, da die ja aus vielen, vielen Samples errechnet wird.
Solltet ihr Fragen haben, versuche ich, sie zu beantworten
Edit: Und für alle, die Lust haben, mit ihren SSL/Traktor/Whatever-Timecodes ihre elektrische Eisenbahn zu steuern ( ), hier ist der Link zu einer C++-Klasse, die beliebige Timecodes im Relative Mode auswertet.
Allen, die nicht wissen, was ein Timecode überhaupt ist, empfehle ich, die Suchfunktion zu benutzen. So, Erklärung anhand der SSL Timecode-CD in drei Schritten:
1. Auswertung der Geschwindigkeit der Platte/CD:
Wie man im Bild erkennen kann, handelt es sich bei dem Timecode-Signal um eine Schwingung mit gleichbleibender Frequenz. Bei SSL beträgt die Frequenz dieses Signals 1000 Hz - pitcht man nun 1% hoch, hat das Signal eine Frequenz von 1010 Hz, pitcht man 0,1% runter, ist die Frequenz 990 Hz. Anhand der Frequenz und der Samplerate lässt sich also relativ einfach der Pitch-Wert errechnen.
Die Frequenz errechnet sich, indem man die Anzahl von "Zero Crossings" (anz) in einem Datenblock zählt, darauf achtet, dass anz modulo 2 = 0 ist (so werden nur ganze Zyklen berücksichtigt), dann anz durch 2 teilt, und diesen Wert wiederum durch die Länge des Datenblocks vom ersten zum letzten Zero Crossings in Sekunden (Anzahl Bytes / Anzahl Kanäle / Samplerate) teilt.
Das Problem hierbei ist, dass es sich um gesamplete Daten handelt. Die Nullpunkte findet man also nicht, indem man überprüft, an welchen Stellen der Wert eines Samples 0 ist - denn die Nullpunkte liegen meist zwischen zwei Samples. Somit ist diese Art der Frequenzmessung nicht besonders genau (für DJ-Zwecke aber wohl ausreichend).
2. Auswertung der Drehrichtung:
Wie man im Bild erkennt, sind der linke und rechte Kanal nicht genau gleich. Sie enthalten scheinbar zwar die selben Daten, sind jedoch in der Zeit verschoben.
Das macht auch Sinn, denn so lässt sich die Drehrichtung ermitteln. Liegen die "Peaks" des rechten Kanals ein gewisses Stück vor denen des linken (rote Linie), läuft die Platte vorwärts. Andernfalls wird gerade rückwärts gedreht.
Das ganze nennt sich Phasenverschiebung, die beträgt im Falle von SSL ca 90°. Hier ist die Samplerate kein Problem, da man im Grunde nur feststellen muss, wo die Position eines Peaks im rechten Kanal (posR) zwischen zwei Peaks im linken Kanal (posL1, posL2) liegt. Gilt posL1 - posR > (posL2 - posL1) / 2, läuft die Platte vorwärts, andernfalls rückwärts. Das würde theoretisch sogar mit einer Samplerate von 5 Samples pro Zyklus funktionieren.
3. Needle Drops/Cueing:
Auch wenn die Funktionen aus 1 und 2 eigentlich schon ausreichen, um ein DVS zu bedienen (sog. Relative Mode), ist es doch wünschenswert, die Nadel wie bei "echtem Vinyl" irgendwo auf der Timecode-Platte abzusetzen und direkt zur entsprechenden Stelle in der MP3 zu springen. Bei SSL scheinen die dafür benötigten "Timestamps" binär in der Lautstärke des Signals kodiert zu sein:
Wer in der Schule aufgepasst hat
weiß, dass Zahlen in binärer Darstellung eine Kombination aus 1en und 0en sind. Dem aufmerksamen Leser stellt sich nun die Frage, woher SSL wissen will, wo das Ende und der Start einer solchen Zahl sein soll. Deshalb schauen wir einmal genauer hin:
Es gibt nicht nur hohe und niedrige Peaks, sondern eher hoch-hohe, hoch-niedrige, niedrig-hohe und niedrig-niedrige. Die hab' ich einfach mal a, b, c und d genannt, sonst kriegt man ja 'nen Knoten im Kopf.
Wenn man genauer hinschaut, sieht man also, dass die Signale auf L und R nicht nur Phasenverschoben sondern auch nicht 100% identisch sind. Ich gehe davon aus, dass diese Unterschiede dazu dienen, den Start, das Ende, etc, eines Timestamps aufzuzeigen. Das System dahinter konnte ich aber auch nach viel probieren und rumrechnen nicht "knacken", ich denke mal, das ist auch so von Serato gewollt. Falls da jemand mehr weiß als ich, kann er mich ja gerne aufklären
So, damit habt ihr dann auch die Erklärung, warum Timecode-Vinyl nach längerer Zeit nicht mehr richtig im Absolute Mode, dafür aber noch praktisch tadellos im Relative Mode funktioniert. Cue Burns, Kratzer, etc, haben einen großen Einfluss auf das sehr sensible Timestamp-System, da nur 1 Wert "kaputt" sein muss, um das ganze System zum Skippen/wilden Rumspringen zu bringen. Der Relative Mode funktioniert dann aber immer noch, da 1 falscher Wert wenig bis gar keinen Einfluss auf die errechnete Frequenz hat, da die ja aus vielen, vielen Samples errechnet wird.
Solltet ihr Fragen haben, versuche ich, sie zu beantworten
Edit: Und für alle, die Lust haben, mit ihren SSL/Traktor/Whatever-Timecodes ihre elektrische Eisenbahn zu steuern (
), hier ist der Link zu einer C++-Klasse, die beliebige Timecodes im Relative Mode auswertet.
Zuletzt bearbeitet:
