Formule in Java omzetten (frequency / sample rate)

[Sir_Hendro]

Ik ben bezig met een stukje audio code in Java waarbij ik frequencies moet genereren door de sample rate van bijvoorbeeld een square wave te veranderen.

Nu heb ik bijvoorbeeld de mogelijkheid om freq 440hz af te spelen welke op 16.000hz is gesampled. Als ik het goed zeg heb ik bij sample 8.000hz een freq 220hz en bij sample 32.000hz een freq van 880 hz. Echter zit er een vergrotende stap tussen de noten dus kun je niet steeds dezelfde waarde er tussen zetten. Dit zie je duidelijk want tussen 220hz en 440 hz zit een verschil van 8.000hz en tussen 440 hz en 880 hz zit 16.000 hz.

Nu zag ik dat je de juiste tussen stappen krijgt door gebruik van log2.

Hier de uitleg over de frequencies van de noten die ik dus wel kunnen vertalen tegen over de sample rate:
Wikipedia: Piano key frequencies

Log2:
Wikipedia: Binary logarithm

En ja, ik had meer wiskunde mogen doen op school. Met basis wiskunde raak je bij programmeren snel in de knoei

[Creepy]

Wil je nu dat wij de formule voor je gaan maken? Want dat is nu net niet de bedoeling hier. Of heb je zelf al wat code geprobeerd en wil je daar hulp mee?

[Cilph]

Ik heb werkelijk geen idee wat je aan het doen bent. Frequencies genereren door een sample rate te varieren? Ik snap niet hoe dat in zijn werk gaat. Wil je een square-wave signaal omzetten naar een sinustoon?

Bijv:

Nu heb ik bijvoorbeeld de mogelijkheid om freq 440hz af te spelen welke op 16.000hz is gesampled.

Deze uitspraak klinkt al compleet als onzin in mijn oren.

[ Voor 62% gewijzigd door Cilph op 06-08-2014 22:58 ]

[Sir_Hendro]

Cilph schreef op woensdag 06 augustus 2014 @ 22:54:
Ik heb werkelijk geen idee wat je aan het doen bent. Frequencies genereren door een sample rate te varieren? Ik snap niet hoe dat in zijn werk gaat. Wil je een square-wave signaal omzetten naar een sinustoon?

Ik heb bijvoorbeeld een square wave (440hz, dat is key 49 op de piano) op een sample rate van 16KHz als fragment. Nu wil ik een soort piano achtige applicatie schrijven die doormiddel van het aanpassen van de sample rate de andere tonen kan generen. Nu weet ik dus dat om het geluid van toets 37 te maken heb ik 220Hz nodig wat ik krijg door de sample rate op 8KHz te zetten of voor key 61 is dat 880 Hz doormiddel van sample rate op 32KHz te zetten.

Echter om de juiste tussen stappen te maken lijkt log2 de juiste toepassing te zijn als ik zo kijk naar de curve die hij maakt. Ik heb alleen nog moeite om deze correct om te zetten naar een stukje Java. Ik zit ondertussen wat te puzzelen met de code

[jeroen3]

Je kunt ook je 440 Hz telkens aanpassen en de samplerate gebruiken voor het octaaf.
Met een beperkt aantal buffers kun je dan alle octaven maken. Ipv dat je de geluidskaart trakteert op fractionele samplerates, want dat vinden ze vast niet leuk.

Of zeg ik nu iets geks?

[Sir_Hendro]

Ik ben nog erg nieuw op het gebied van audio programmatuur. Zover ik weet blijft het allemaal softwarematig waarbij je teveel of te weinig samples aan het genereren bent waardoor je sample rate niet gelijk loopt aan die van je geluidskaart. Hierdoor zijn dan wat artifacts te horen in het geluid dat je genereerd. Dit kan je dan volgens mij vergelijken met games waar je videokaart 240 fps aan het maken is omdat je V-Sync hebt uitstaan terwijl je monitor TFT maar 60 fps kan laten zien.

Maar deze bewering durf ik niet te garanderen, het is goed mogelijk dat ik hier poep praat.

[Laurens-R]

My 2 cents vanuit mijn Windows Audio API ervaringen. Misschien heb je er wat aan:

In mijn geval ging het bij artefacten vaak om buffer timingsproblemen die je hebt als je on-the-fly realtime audio genereerd. Ik zal even mijn bevindingen hieronder neerzetten. .

In windows open je een buffer naar je geluidskaart die constant word uitgelezen op de aangegeven sampling snelheid. (Bijv. 44100Hz met 16 bits per sample). Dat is gewoon een constante gedurende je audio 'sessie'. Om realtime tonen te genereren en te streamen moet je dus binnen een seconden 44100 van die samples in je buffer stoppen. Als de software echter even hapert kan het zomaar zijn dat je net 25ms te laat bent met het vullen van de buffer. Dan krijg je een hik. Een oplossing zou zijn dat je een paar secondes vooruit buffert. Alleen hoe meer je vooruit buffert, hoe groter de delay word tussen bijv. het indrukken van een toets op je keyboard en het daadwerkelijk weergeven van het geluid. Maar dat is niet speelbaar. Je zal dus een balans moeten vinden tussen vooruit bufferen en toch de delay zo kort mogelijk te houden. (1 van de redenen waarom ASIO bestaat; daarmee kan je sneller/directer de audio buffer van de geluidskaart benaderen en zodoende de delay/latency zo kort mogelijk maken).

Een ander probleem kan zijn dat je (zoals je zelf al aangeeft) je toon frequentie niet helemaal in lijn loopt met je output signaal (in ons geval 44100Hz). Dit kan een aantal redenen hebben; maar kwam bij mij vaak neer op interpolatie en oversampling issues.

Stel je het geval van een 400Hz sinuswave voor. Je zou denken; dat zijn 400 samples verdeeld over 44100Hz (dus 44100 / 400 =~ 110). Dat zijn 110 samples die overbrugt moeten worden voor het zetten van elke sinus sample. Dit is eigenlijk undersampling, en je zal zien waarom: Je zou kunnen zeggen; we stellen 110 samples in op dezelfde waarde tot het volgende sinus punt. Dan krijg je een artifact (hoewel dit effect ook opzettelijk toegepast kan worden). De golf word immers hoekig (trap effect).

Dan kan je nog lineair gaan interpoleren... nog steeds geen mooie golflijn, maar een rechte lijn tussen de sinus punten (vergelijk het maar met een low poly 3D model, die gehoekt is waar het rond zou moeten zijn).

Dan kan je nog ook spline interpolatie gebruiken. Daarmee maak je een mooie rond vloeiende lijn tussen de sinus sample punten.

Het probleem van alle bovengenoemde oplossingen is echter dat je alle tonen eigenlijk aan het fixen bent waar je eigenlijk gewoon meer samples had moeten genereren. (of dit nou een sinus golf of square wave golf is). Deze interpolatie (evt. icm eerder genoemde buffer uitdagingen) zorgt vaak voor artefacten. Je moet in bovenstaande voorbeeld de sinus ook uitrekenen voor alle tussenliggende samples (en dus niet interpoleren).

In de opname techniek zorgen ze bijvoorbeeld dat er altijd minimaal 2x zoveel (of meer) gesampled word dan wat de output zal zijn (en daarom genaamd: oversampling). (bijv: een CD opname voor 44100hz dragers word opgenomen op 96000Hz).

Kern van het verhaal; zorg dat je genoeg informatie/samples hebt zodat het gegeneerde signaal niet opbreekt en de uitlijning van het signaal blijft kloppen in verhouding tot je output.

Anyway.... als je jezelf een beetje wilt wapenen tegen dit soort type problemen (artefacten, timings problemen, interpolatie, etc) is het misschien handig als je jezelf iets dieper ingraaft in de theorie rondom sampling (inclusief under en oversampling)

[ Voor 10% gewijzigd door Laurens-R op 07-08-2014 00:30 ]

[Sir_Hendro]

@Laurens-R
Bedankt voor jouw feedback. Er zit zeker goede uitleg tussen.

Wat de frequentie omzetten vanaf slechts 1 sample file. Ik heb even wat info doorgenomen en na wat calculaties zag ik dag tussen iedere key de frequenctie steeds met 5,94xxx omhoog of omlaag gaat. Hiermee deed ik dan hetzelfde bij de sample rate van het fragment. Dit resulteerde in enigsinds iets wat erop begint te lijken. Ik moet wel even reference frequenties vastleggen want als ik slechts 1 variable gebruik voor de huidige frequentie en daar steeds x% vanaf haal en weer bij tel klopt na een tijdje de waarde van de frequentie net niet helemaal. Daarom ga ik nu een reference lijst aanmaken en steeds op basis daarvan een frequentie generen. Hierdoor kloppen de toonhoogtes voor 99,99%, goed genoeg voor het begin

//Edit
Oke ik heb het nu werkend gekregen. Basis piano spelen met sound samples is nu mogelijk. Nu het programma verder ontwikkelen met meer mogelijkheden zoals invloed hebben over hoe de samples moet worden afgespeeld ect.

[ Voor 12% gewijzigd door Sir_Hendro op 07-08-2014 11:44 ]