2016-07-22 12 views
6

Utworzono metodę getSpectrum za pomocą metody getByteFrequencyData w węźle analizatora API Web Audio API. Tablica zwróconych danych dźwiękowych jest względna względem źródła dźwięku (instancji el lub Audio()): volume, wartość od 0 do 1.Normalizacja danych audio z getByteFrequencyData według wolumenu

Używanie woluminu źródła dźwięku Próbuję normalizować każdą otrzymaną wartość od getByteFrequencyData, dzięki czemu użytkownik getSpectrum nie musi martwić się głośnością podczas wizualizacji danych audio.

ten jest rozłożony w dół wersja getSpectrum

var audioData = new Uint8Array(analyser.binCount); 
var spectrum = []; 

analyser.getByteFrequencyData(audioData); 

for (var i = 0; i < audioData.length; i++) { 
    var value = audioData[i]; 

    //Where I'm trying to calculate the value independent of volume 
    value = ((value/audioEl.volume)/255); 

    spectrum.push(value); 
} 

return spectrum; 

W W3C spec równanie odniesienia wykorzystuje się do obliczenia wartości zwracane którym podano maxDecibels i minDecibels. Z moim podstawowym zrozumieniem, próbowałem odwrócić matematykę, więc otrzymuję znormalizowaną wartość, ale nie mogę jej poprawnie działać. Mam problem z osiągnięciem tego z tylko wartością objętości od 0 do 1.

Wszelkie podżeganie byłoby bardzo cenne! Oto problem z numerem working example. Zmiana suwaka głośności zilustruje problem.

Aktualizacja 7/22/16: Dzięki odpowiedzi @ raymond-toy zrozumiałem, jak przekonwertować wartość woluminu od 0 do 1 na decybele.

volumeDB = Math.abs((Math.log(volume)/Math.LN10)*20); 

Po zdobyciu DB, ja odwróconej równanie w specyfikacji W3C,

value = ((audioDataValue * volumeDB)/255) - volumeDB 

Niestety value jakoś nadal kończy się względem volume. Czy ktoś widzi, czego mi brakuje?

+1

Można obejść ten problem poprzez umieszczenie GainNode w między '' analyser' i swoim kontekście. cel podróży'. Wtedy miałbyś suwak głośności, który dostosował GainNode zamiast głośności dźwięku. W ten sposób objętość zostanie skorygowana dopiero po przejściu przez twój "analizator". – idbehold

+0

Nad czym pracuję, nie miałbym kontroli nad tym, co ustawia wolumin, więc nie byłbym w stanie umieścić GainNode przed tym, co by było. To dobry pomysł. Rozważymy to dla innych projektów. –

Odpowiedz

1

Najwyraźniej byłem na misji głupca. Jak wskazał @raymond-toy, wartości widma są pośrednio w stosunku do objętości. Normalizowanie oznaczałoby utratę części danych "poza spektrum", co nie było moim celem.

Jeśli ktoś jest ciekawy, skończyło się tylko podzielenie audioDataValue przez 255, coraz pływaka od 0 do 1.

1

getByteFrequencyData zwraca wartości w dB. Nie chcesz dzielić tych wartości przez plik audioE1.volume. Chcesz przekonwertować (jakoś!) AudioE1.volume do wartości dB i dodać (lub odjąć), która z wartości od getByteFrequencyData

To może być łatwiejsze do zrozumienia rzeczy, jeśli użyto getFloatFrequencyData pierwsze, aby zobaczyć co się dzieje.

+0

To był świetny pierwszy krok. Znaleziono matematykę, która zmieniła 0 do 1 woluminu na DBs 'Math.abs ((Math.log (volume) /Math.LN10) * 20)'. Podłączanie tego do równania odwrotnego do specyfikacji w3c nie działało. 'value = ((audioDataValue * volumeDB)/255) - volumeDB;' "Wartość" nadal kończy się w stosunku do głośności w jakiś sposób. IDK, co robię źle. –

+1

Myślę, że lepiej Ci idzie z value = audioDataValue - volumedB. Nie dziel według volumeDB; dzielenie dwóch wartości dB nie ma większego sensu. I nie rozumiem, dlaczego chcesz normalizować widmo. To nie będzie działać poprawnie z getByteFrequency, ponieważ w miarę zmniejszania się objętości, i tak stracisz wartości spoza spektrum. –

+0

Widzę, co mówisz. Odejmowanie ma sens, po prostu nie wiedział, że to działa w ten sposób. Zakładam, że zmiana wartości audioDataValue jest w jakiś sposób proporcjonalna do poziomu głośności. Wypróbuję to –