→ kdjf:輸出的DA也只跑在90khz.... 再高上去也沒有用 140.112.245.32 03/01 17:07
→ uranusjr:準到毫秒的話 1/3 一秒也只會差一毫秒 220.133.47.18 03/01 18:13
→ uranusjr:也就是曲子要超過 16 分鐘才會有一秒誤差 220.133.47.18 03/01 18:14
→ uranusjr:對人類而言根本沒差... 220.133.47.18 03/01 18:14
對，我知道音樂這種東西畢竟是要給人類聽的，不必太在意細節，
但我想知道...有沒有某種大家都講好的協定？
如果不同的音訊處理用不同的頻率算法，
歌曲一長，最後還是會聽得出來吧？
※ 編輯: stu87616 來自: 120.125.7.18 (03/01 18:59)
推 snowlike:唔..我不太明白為什麼誤差可以累增近一秒 114.44.108.14 03/01 20:01
→ kdjf:先想想看你的"音開始"要怎麼在聲波中定義 140.112.245.32 03/02 22:53
→ kdjf:看對聲波要多久取一個樣,接著就把拍子round 140.112.245.32 03/02 22:55
→ kdjf:到對接近的點 140.112.245.32 03/02 22:55
推 shietsd:精細度跟你用到的硬體有關 61.57.152.2 03/03 18:48
→ shietsd:如果你是用mcu類的發音 處理器都是MHZ等級 61.57.152.2 03/03 18:49
→ shietsd:精細度至少是 us 如果是說win 平台上的音 61.57.152.2 03/03 18:50
→ shietsd:效卡之類的 上面的處理器應該更快 61.57.152.2 03/03 18:50
推 shietsd:至於除不盡的問題 基本上算式是以 MCU 產 61.57.152.2 03/03 18:54
→ shietsd:生多少波形來算的(方波) 所以每次都會更新 61.57.152.2 03/03 18:54
→ shietsd:波形數 理論上誤差不應該會累積 61.57.152.2 03/03 18:54
→ kdjf:音效最高只有看過19xkHz的...,重點在有DA所以 140.112.245.32 03/04 01:42
→ kdjf:不是方波吧 140.112.245.32 03/04 01:42
推 shietsd:因為原PO問題在於音樂曲調與電腦運作的差 61.57.152.2 03/04 19:00
→ shietsd:異 所以我直覺是認為他是在問 AD 的誤差 61.57.152.2 03/04 19:01
抱歉，其實我根本看不懂AD和DA這些縮寫是啥(汗
看你們提到波型之類的，似乎是指wav音頻，
我主要是想問，像是midi這類由電腦自行生成的類型，
速度的儲存位址可能就只有一個數字(BPM)，那能夠多嚴謹？
※ 編輯: stu87616 來自: 1.163.69.63 (03/05 00:24)
→ azureblaze:midi的bpm是推算出來的 118.168.57.194 03/05 01:37
→ azureblaze:實際儲存的是每拍時間長度(整數微秒) 118.168.57.194 03/05 01:38
↑↑↑↑就是這個
這個"整數微秒"怎麼決定好的?
如我在意的，一定除不乾淨嘛，怎麼處理那些餘數？
→ azureblaze:另外再一個整數決定每拍幾個tick 118.168.57.194 03/05 01:38
→ azureblaze:所有的事件都會發生再tick上 118.168.57.194 03/05 01:38
→ azureblaze:所以其實全部都是整數運算 118.168.57.194 03/05 01:39
→ azureblaze:至於跟實際時間的差距 118.168.57.194 03/05 01:39
→ azureblaze:一般應用會以音樂時間為準 118.168.57.194 03/05 01:40
→ azureblaze:所以根本不會去理實際時間 118.168.57.194 03/05 01:43
※ 編輯: stu87616 來自: 1.162.164.225 (03/05 10:40)
→ azureblaze:除不乾淨就除不乾淨啊 1.171.59.231 03/05 10:53
→ azureblaze:從計時器開始就不準了 1.171.59.231 03/05 10:54