Kleines Sequencerparadoxon...?

hallo!

Folgendes Problem:

bei 120 bpm hat ein loop fon 4 takten länge eine dauer von genau 8 sekunden und bei einer abtastrate von 44,1khz auch genau 352800 samples.

ein delay welches auf den host gesynct ist hätte also wohl keine probleme perfekt in sync zu blieben, egal wie lange es irgend einen sound delayt, es bleibt im zweifelsfall für jahre perfekt samplegenau in sync. soweit schon mal keine einsprüche? gut.

was wenn ich nun aber 121bpm wähle? bei 121 bpm hat ein loop von beispielsweise 4 takten keine gerade sampleanzahl mehr, das problem: samples können nicht geteilt werden, oder doch?

cubase sagt mir mein loop von 4 bars wäre bei 44.1khz genau 349884 lang - was nicht stimmen kann, denn 121 bpm sind genau 1,0083333333333333333333333333333(periodisch..) mal mehr als 120 bpm, das heißt ein loop mit 4 takten länge der bei 120bpm und 44.1khz abtastrate noch genau 352800 samples lang ist muss bei 121 bpm um den kehrwert von 1,0083333333333333333333333333333(periodisch..) kürzer sein, was ungefähr (nicht alle stellen ausgerechnet, da das ja unmöglich wäre) 0,99173553719008264462809917355405 ergäbe.

0,99173553719008264462809917355405 mal 352800 samples ergibt 349884,29752066115702479338842987 samples

ein audiofile kann aber nicht 349884,29752066115702479338842987 samples haben, oder doch?

darum wundere ich mich nun wie cubase das nun intern macht. rechnet es intern mit festen runden sampleeinheiten, so wie bei der auswahl der 4 takte bei 121 bpm wo er mir sagt das wären 349884 samples, was es ja nicht sein können, oder rechnet es doch irgendwie intern mit fließkommasamplewerten oder eben nachkomma samplelängen wie man auch immer das nennen will.

Im ersteren fall wäre die angabe 121bpm dann falsch, wenn man 349884 samples für 4 takte bei 121 bpm annnimmt, dann hat man nie und nimmer exakt 121 beats die munite, sondern ganz leicht mehr oder weniger (hab das nicht ausgerechnet..) und dieser Umstand ist zum kotzen, dann soll da halt nicht 121 stehen, sondern das was es aufgrund der abtastrate an bpm nahe dem Wunschwert möglich wäre! oder?

also was ist bei cubase das worauf man sich bezieht, ist die bpm zahl die fixe größe, oder die samplezahl? kann ja auch sein dass er durch irgendwelche ausgefuchsten tricks nach jedem takt oder an gewissen stellen einfach die abspielgeschwindigkeit so variiert dass man den zu den Abtastraten unpassenden bpm zahlen zuvorkommt.

Das wäre aber ein mordsaufwand einer audioengine.

Also die frage ist wirklich worauf bezieht sich cubase, wenn ich nämlich audiofile gemäß 121bpm auf 4 takte ausschneide und es 1000 mal loope, müsste es komplett out of sync mit dem projekt sein, da es ja anscheinend intern auf 349884 samples und nicht auf 349884,29752066115702479338842987(usw) aufgelöst wird. und halbe samples gibts ja nicht...das weiß ich ja. aber vielleicht ja doch.

alles ziemlich verwirrend.

aber es wäre gut das zu klären, sonst hat man irgendwann massive probleme wenn man ganz große projekte plant die lange laufen sollen und sich vielleicht selbst generieren und loopen und naja...ihr wisst ja

samplegenauigkeit in allem was passiert sollte kein feature sein, sondern unumstößliche grundlage eines jeden sequencers

also bisher dachte ich mir es wäre um der genauigkeit willen sinnvoll halt nur in bpms zu arbeiten, die "endlich" oder "finit" (nicht periodisch..) mit der abtastrate teilbar sind,bpm: 80, 84, 90, 98, 100, 105, 112, 120, 125, 126, 128, 140, 144, 147, 150, 160...usw (also bei 44,1khz sind das die "runden" bpm, bei 48khz sieht das schon wieder anders aus...aber wer nimmt schon 48khz...ich nicht ;-))

aber nun möchte ich mal wissen wie das der sequencer intern so macht, immerhin ergeben sich alle anderen bpm dadurch massive ungenauigkeitsprobleme

gruß
lee
 
tomylee schrieb:
hallo!
Also die frage ist wirklich worauf bezieht sich cubase, wenn ich nämlich audiofile gemäß 121bpm auf 4 takte ausschneide und es 1000 mal loope, müsste es komplett out of sync mit dem projekt sein..

das wäre ein loop von ca. 132 minuten länge!!! krass.
ist das überhaupt noch relevant für musikstücke die sich in der regel zwischen 2-10 minuten bewegen?
 
trigger schrieb:
tomylee schrieb:
hallo!
Also die frage ist wirklich worauf bezieht sich cubase, wenn ich nämlich audiofile gemäß 121bpm auf 4 takte ausschneide und es 1000 mal loope, müsste es komplett out of sync mit dem projekt sein..

das wäre ein loop von ca. 132 minuten länge!!! krass.
ist das überhaupt noch relevant für musikstücke die sich in der regel zwischen 2-10 minuten bewegen?

nein das ist nur noch für megaelitäre kunstmusik relevant ;-)
 
okay, das ist natürlich was anderes! ;-)

trotzdem spannende rechnung. man sehen was die algebrainformatiker dazu sagen.

vg
 
Mein Primitifst-Taschenrechner sagt Cubase lügt und macht in Wahrheit 121,0001 ( vielleicht sind da noch mehr Nullen vor der letzten 1) BPM.
Vielleicht machts Cubase auch wie die Normalsterblichen mit dem Kalender und fügt alle paar Minuten ein "Schaltsample" ein. ;-)
 
Hoi,

Es sprach der Informatiker:

Computer nutzen je nach dem Festkomma- oder Fliesskomma-Arithmetik bei solchen Berechnungen. Es gibt dort kein 1.0(periode)3.
Intern hat Cubase wohl 32 oder 64 bit Float-Variablen für solche Berechnungen:
To a rough approximation, the bit representation of an IEEE binary floating-point number is proportional to its base 2 logarithm, with an average error of about 3%. (This is because the exponent field is in the more significant part of the datum.) This can be exploited in some applications, such as volume ramping in digital sound processing. http://en.wikipedia.org/wiki/Floating_point


Genaue Details siehe : http://en.wikipedia.org/wiki/IEEE_754-2008 :



Gruss Mink
 
das mag ja sein, trotzdem würde mich interessieren wie cubase das intern macht wenn ich ein 4 takter bei 121bpm 1000 mal loope und dazu ein file hernehme das mit exakt 121 beats pro minute als tempo aufwartet, müssten sich einige beats unerschied ergeben..

cubase kann dateiformate auch nicht überlisten, ein 44,1khz file hat nun mal nur 44.100 möglichkeiten pro sekunde, etwas zu definieren (in dem fall einen datenstrom, sozusagen) und wie gesagt, cubase scheint da zu runden, da es für 4 takte bei 121bpm 349884 samples festlegt, obwohl es eigentlich 349884,29752066115702479338842987(usw) samples sein müssten.

Nochmal: wenn ich dieses sample nun 1000 mal hintereinander setze, müssten sich große abweichungen zeigen, da es eben nicht perfekt ist.

woher soll cubase auch wissen dass das file das ich meine eigentlich 349884[komma irgendwas] samples, anstatt exakt 349884 samples lang ist?

der fehler ist wohl notwendig, oder was sagt der informatiker hierzu?

schafft es cubase sein versprechen von 121bpm exakt einzuhalten oder ist das aufgrund der terminologie hier nicht möglich und er macht doch 121,00001 oder sowas? ich halte es für kaum möglich dass cubase es schafft die angabe einzuhalten, da es eigentlich nicht möglich sein dürfte. Fließkomma hin oder her. Ich meine gewisse bpm sind für gewisse abtastraten wohl schlicht und einfach nicht exakt realisierbar. so auch 121 bpm im vergleich zu 120 und den anderen die ich genannt habe..

wäre gespannt auf eine Antwort mink
 
Wie ja schon festgestellt wurde, ist die resultierende Abweichung so klein, dass sie nicht ins Gewicht faellt. Die 121bpm werden einfach auf die naechstpassende Samplezahl gerundet und fertig. Die Taktung von Computern ist sowieso nicht so exakt, dass ein und dasselbe Stueck auf zwei Rechnern nebeneinander unsynchronisiert abgespielt nicht auch nach ziemlich endlicher Zeit ein Sample daneben liegt.
Roadrunner
 
bei 120 bpm und den anderen werten die nicht gerundet werden müssen sollte es aber funzen, auch system und clockübergreifend, es sei denn alle seqeuncer runden auf die gleiche art, dann wäre es auch bei 121 möglich...

na mal sehn was sich da noch so ergibt.. :)
 
Wenn du Loops aneinander reihst wirst du doch sicher auf das vorgegebene Grid (zB Viertel) ausrichten, oder?
Je nach Rundung fehlt dann am Loopende etwas, oder es überlappt. Jedenfalls ist bei der nächsten Ausrichtung die Welt wieder in
Ordnung und die differierenden Frame-Bruchteile sind nicht zu hören.

Selbst wenn du nahtlos aneinander reihst, also ohne Quantisierung) hast du nach 100 Einzel-Takten nur einen Fehler von 77 frames.
Bei dem Tempo ist das ungefähr eine Tausendstel-Note. ;-)
 
mc4 schrieb:
Wenn du Loops aneinander reihst wirst du doch sicher auf das vorgegebene Grid (zB Viertel) ausrichten, oder?
Je nach Rundung fehlt dann am Loopende etwas, oder es überlappt. Jedenfalls ist bei der nächsten Ausrichtung die Welt wieder in
Ordnung und die differierenden Frame-Bruchteile sind nicht zu hören.

Selbst wenn du nahtlos aneinander reihst, also ohne Quantisierung) hast du nach 100 Einzel-Takten nur einen Fehler von 77 frames.
Bei dem Tempo ist das ungefähr eine Tausendstel-Note. ;-)

ja ich hab bisher noch keine praktischen probleme damit, wollte eigentlich nur im voraus sicherstellen dass ich keine haben würde, ich muss einfach mit den bpms arbeiten die sich als sample ganzzahlig ausdrücken lassen.
 
Du glaubst auch alles, oder? ;-) In diesem Fall die Tempoangabe...

Ohne einen Beweis zu haben: Die Tempoangabe richtet sich nicht nach der Atomuhr der PTB in Braunschweig sondern nach der nächstliegenden ganzzahligen Samplezahl.
 
florian_anwander schrieb:
Du glaubst auch alles, oder? ;-) In diesem Fall die Tempoangabe...

Ohne einen Beweis zu haben: Die Tempoangabe richtet sich nicht nach der Atomuhr der PTB in Braunschweig sondern nach der nächstliegenden ganzzahligen Samplezahl.

ja ich bin recht leichtgläubig bei klaren großen zahlen in meinem seqeuncer, wie gesagt, sollen die halt niciht 121bpm schreiben sondern die anzeige automatisch darauf einstellen was tatsächlich möglich ist, in dem fall wohl die 121,0001 oder so..
 
Dann würden sich aber viel mehr User beschweren, dass Eingaben nicht genau übernommen werden. Wir leben in einer digitalen Welt - da ist zunächst einmal alles gerundet und immer etwas daneben. Je weniger daneben, desto besser - aber es ist absolut sicher, dass Digital immer nur eine Annäherung an die Wirklichkeit darstellt. Wir haben aber Gott sei Dank bereits einen Level an Genauigkeit erreicht, dass uns das im Grunde egal sein kann.
 
im extremfall ist es immer gut über die dinge gründlich bescheid zu wissen, wenns denn mal so weit kommt dass man sowas benötigt ist man froh dass man die überlegung gemacht hatte, ich bin jedenfalls nun froh darüber zu wissen dass mein sequencer in realität gar keine 121 (exakt) bpm liefern kann, obwohl man das einfach schwer annimmt, und sowas normalerweise niemals hinterfragen würde.
 
Wenn Du die Berechnungen auf die Quantisierung ausdehnst, wirst Du noch ganz andere Überraschungen erleben. Vor allem, wenn Du noch MIDI Instrumente einsetzt. Es werden in der Regel Sequenzerauflösungen und Quantisierungsraster angeboten, die es aufgrund der verwendeten Technik gar nicht geben dürfte. Auf dem Papier sieht das trotzdem immer ganz toll aus und es fühlt sich prima an, wenn sich das Tempo mit drei Nachkommastellen eingeben lässt;-)
 
ja stimmt, eigentlich ist quantisierung auch nicht exakt möglich, also nicht zeitgeeicht sozusagen - sondern ist wohl eben samplebasiert - wobei wie war das mit den frames? die sind nur für video relevant denkich
 
Midi-Takt sind 96tel. Das sind bei 120 Bpm 48Hz oder 918.75 Samples.
Das man hier nicht erst Runden und dann akkumulieren darf ist relativ klar. Effektiv wird man also nach drei mal nach 918 und einmal nach 919 Samples eine Midi-Clock schicken, so das der Fehler immer kleiner als 1 Sample bleibt. So kann man das, mit mehr oder weniger Aufwand und Trickserei, fast überall machen.

Die Werte zwischen den Samples sind eindeutig definiert (sonst könnte man sie nicht weglassen), es ist also durchaus möglich, einen Trackteil um 0,8765 Samples zu verschieben. Das erfordert allerdings Resampling und wird daher wohl nicht gemacht...
 


News

Zurück
Oben