Muusikoiden.net
17.04.2024
 

Tietokoneet ja musiikkiohjelmat »

Keskustelualueet | Lisää kirjoitus aiheeseen | HakuSäännöt & Ohjeet | FAQ | Kirjaudu sisään | Rekisteröidy

Aihe: Mikä näytteenottotaajuus ja bittisyvyys on ideaali?
1 2 3
Jaava
31.05.2015 18:46:13 (muokattu 31.05.2015 18:46:38)
      Linkitä kirjoitukseen Tulosta  

mhelin: 32-bit flotareilla dynamiikka-alue on 1680 dB, mutta resoluutio paljon vähemmän (samaa luokkaa tai vähän parempi kuin 24-bittisellä kokonaisluku datalla). Kyse ei ole bittisyvyydestä vaan numeroiden esitystavasta. Flotarit siis esitetään exponenttilukuina.
Paras tietty olisi että muuntimet tuottaisivat valmiiksi taajuusmuotoista dataa (kuten FFT:llä PCM:stä tuotettu), sitä olisi helpoin prosessoida.

 
Mä tiedän mitä floating point tarkoittaa kiitos vain. Tämä ei vastannut mun kysymykseen. Mitä sä ajattelit saavuttaa sillä, että muuntimet tuottaisivat 32bit floating pointtia?
 
Ja miten sä ajattelit ton FFT-jutun toimivan? Mitä se muunnin työntäisi ulos?
 
"Katastrofien ei pitäisi kestää näin kauan, haluan aamiaista!"
JPQ
01.06.2015 02:00:54
Musiikkinäyte       Linkitä kirjoitukseen Tulosta  

48khz komentistani luotan siihen mitä isot pojat ovat antaneet toimitta ohjeeksi ja puhun filmistä itse en videosta. eli leffateatteri kohteena kait sielläkin se standardi näin olen oppinut.
 
Laajan musiikkityylien kirjon edustaja. Tähän asti kehutuin kappale musiikki näytteessä download linkkinä. Ehkäpä toinen puolisko tyylistäni jota eniten edustan.
PIM
01.06.2015 10:49:46
      Linkitä kirjoitukseen Tulosta  

mhelin:
 
Noista audioformaateista jäänyt mainitsematta 32-bittinen floating point jota voisi olla jossain tapauksissa syytä käyttää, ainakin silloin kun tekee välimiksauksia (mille ei ehkä nykyään niin tarvetta) tai äänittää efektien kautta (esim. sähkökitaraa vahvistinsimulaattorin kautta). Flotariformaatit nimittäin eivät itsessään klippaa kuten kokonaislukuformaatit. A/D-muuntimien klippausta tuolla ei tietenkään saa estettyä. Jotkut daw-softat kuten Cubase myös käyttävät sisäisesti 32-bittistä floating point formaattia jolloin tuota muunnosta ei tarvitsisi silloin tehdä uudestaan.

 
Eikös lähes kaikki tunnetut DAWit ole jo viimeiset 15 vuotta käyttäneet sisäisesti 32 bittistä floating point laskentaa? Se, että muuntimen tuottama 24 bittinen kokonaisluku konvertoidaan 32 bittiseksi liukuluvuksi ja päin vastoin ei liene maailman vaikein tai edes kuormittavin laskutoimitus. Itse en ymmärrä mitä järkeä olisi liukulukuja tuottavassa AD muuntimessa, kun kerran muuntimen analogipuoli toimii kuitenkin tietyllä kiinteällä exponentilla.
 
Kamaahan on sopivasti, tilaa vaan liian vähän.
mhelin
01.06.2015 18:31:52
      Linkitä kirjoitukseen Tulosta  

Jaava: Mä tiedän mitä floating point tarkoittaa kiitos vain. Tämä ei vastannut mun kysymykseen. Mitä sä ajattelit saavuttaa sillä, että muuntimet tuottaisivat 32bit floating pointtia?
 
No ensinnäkin sen että FP-ADC:lla ei tarvitsisi enää juuri välittää äänitystasoista, riittää kun signaalia tulee riittävästi, ja mielellään ehkä enemmänkin. FP-ADC ei siis ole sama asia kuin tavallinen ADC joka konvertoi datan FP:ksi, sen pitäisi skaalautua suurempiin sisääntulojännitteen vaihteluihin vaikka resoluutio olisi vaikka vain sen 16 tai 24 bittiä. Yksinkertaisin toteutus olisi AGC (haittana hitaus), monimutkaisemmassa tarvitaan useampia A/D muunnoksia ja muuntimia pipelinessa.
 
Ja miten sä ajattelit ton FFT-jutun toimivan? Mitä se muunnin työntäisi ulos?
 
A/D muunnin sisältää jo nykyäänkin DSP-koodia joka tuottaa ylinäytteistetystä A/D konvertoidusta datasta halutun esim. 24-bit @96kHz PCM datan. Yhtä hyvin se voisi tehdä myös FFT:n. FFT:n tulos olisi jotain MP3 tapaista binääridataa jossa yksittäisen sämplen sijaan esitetään FFT analyysin tulos joka on yksinkertaistettuna lista harmonisia taajuuksia (siis siniaaltokomponentteja) ja niiden amplitudi (joskus myös vaihe). Analyysi tehtäisiin esim. 128 sämplestä (voi olla jotain muutakin, MP3:ssa käytetään 192 sämpleä transienteille ja 576 muulle signaalille). Datamäärän suhteen jonkinlainen adaptiivinen algoritmi olisi varmaan hyödyllinen datamäärän pitämiseksi kohtuullisena tarkkuuden kärsimättä.
 
Käytännössä tuo FFT-muunnos olisi varmaan järkevämpi tehdä audio interfacessa esim. FPGA:lla (tai DSP:llä) samaan tapaan kuin RME:n interfacessa tehdään ASIO I/O prosessointia ("ASIO in hardware" mainostivat joskus).
 
Jaava
01.06.2015 18:57:58
      Linkitä kirjoitukseen Tulosta  

mhelin: No ensinnäkin sen että FP-ADC:lla ei tarvitsisi enää juuri välittää äänitystasoista, riittää kun signaalia tulee riittävästi, ja mielellään ehkä enemmänkin. FP-ADC ei siis ole sama asia kuin tavallinen ADC joka konvertoi datan FP:ksi, sen pitäisi skaalautua suurempiin sisääntulojännitteen vaihteluihin vaikka resoluutio olisi vaikka vain sen 16 tai 24 bittiä. Yksinkertaisin toteutus olisi AGC (haittana hitaus), monimutkaisemmassa tarvitaan useampia A/D muunnoksia ja muuntimia pipelinessa.
 
Sä varmaan viittaat tuolla "skaalautuu suurempiin vaihteluihin" -fraasilla dynamiikan määrään, joka määritellään pienimmän ja suurimman mahdollisen signaalin suhteella toisiinsa. Tämä dynamiikkataso kääntyy käytännössä kohinatasoksi ts. sillä ei ole oikeastaan muuta merkitystä kuin se, minne digitaalinen pohjakohinataso asettuu. Jo 24bittisellä kokonaislukudatalla digitaalisen epätarkkuuden aiheuttama kohina asettuu reilusti alemmaksi kuin järjestelmän analogisten komponenttien kohina. 24bit systeemissä teoreettisen dynamiikan määrä on myös enemmän kuin mitä ihmisen kuuloaisti pystyy erottamaan. 32bittinen FP-systeemi varmasti tarjoaisi enemmän dynamiikkaa, mutta mitä hyötyä siitä on kun järjestelmän rajoitteet tulevat vastaan muissa komponenteissa ja viimeistään ihmisen korvassa? Jos nyt sitten joku valittaa, että tarvitsisi äänitystasoja jotenkin erityisesti tarkkailla 24bittisenä äänittäessä niin höpönlöpön. Vaikka äänittäisi vain 1/10 maksimitasosta, on dynamiikkaa silti käytössä reippaasti enemmän kuin 16bittisessä lopputuotteessa ja vielä huomattavasti paljon enemmän kuin parhaissakaan analogisissa järjestelmissä.
 
Eli mitä konkreettista etua saavutettaisiin, jos nykyiset 24bit fixed point systeemit korvattaisiin 32bit flotareilla?
 
A/D muunnin sisältää jo nykyäänkin DSP-koodia joka tuottaa ylinäytteistetystä A/D konvertoidusta datasta halutun esim. 24-bit @96kHz PCM datan. Yhtä hyvin se voisi tehdä myös FFT:n. FFT:n tulos olisi jotain MP3 tapaista binääridataa jossa yksittäisen sämplen sijaan esitetään FFT analyysin tulos joka on yksinkertaistettuna lista harmonisia taajuuksia (siis siniaaltokomponentteja) ja niiden amplitudi (joskus myös vaihe). Analyysi tehtäisiin esim. 128 sämplestä (voi olla jotain muutakin, MP3:ssa käytetään 192 sämpleä transienteille ja 576 muulle signaalille). Datamäärän suhteen jonkinlainen adaptiivinen algoritmi olisi varmaan hyödyllinen datamäärän pitämiseksi kohtuullisena tarkkuuden kärsimättä.
 
Käytännössä tuo FFT-muunnos olisi varmaan järkevämpi tehdä audio interfacessa esim. FPGA:lla (tai DSP:llä) samaan tapaan kuin RME:n interfacessa tehdään ASIO I/O prosessointia ("ASIO in hardware" mainostivat joskus).

 
Mutta mitä hiton apua siitä olisi kenellekään, jos interface tai muunnin tekisi fouriermuunnosta signaalista? Lisää latenssia ja ylimääräistä dataa siirrettävänä? Eiköhän se muunnos synny sitten kätevästi, jos sitä tarvitaan, eikä muuta järjestelmää tarvitse rasittaa. Kyllähän ne interfacet tekee usein simppeliä FFTtä omaa mittarointia varten, mutta ei se prosessointi signaaliketjussa ole.
 
"Katastrofien ei pitäisi kestää näin kauan, haluan aamiaista!"
mhelin
01.06.2015 20:55:32
      Linkitä kirjoitukseen Tulosta  

Jaava:
Mutta mitä hiton apua siitä olisi kenellekään, jos interface tai muunnin tekisi fouriermuunnosta signaalista? Lisää latenssia ja ylimääräistä dataa siirrettävänä? Eiköhän se muunnos synny sitten kätevästi, jos sitä tarvitaan, eikä muuta järjestelmää tarvitse rasittaa. Kyllähän ne interfacet tekee usein simppeliä FFTtä omaa mittarointia varten, mutta ei se prosessointi signaaliketjussa ole.

 
FFT ja iFFT vie kaikista eniten prossutehoja kaikesta DAW DSP prosessoinnista. Jos ne voisi ulkoistaa muuntimille / audio interfacelle ei tarvittaisi mitään välimuunnoksia. Nyt kanavan signaaliketjussa voi olla peräkkäin monta efektiä jotka jauhavat tuota FFT -> prosessointi -> iFFT ketjua edes takaisin. Lisäksi konvoluutiokaiut ja master kompurat. Jos MP3 on riittävällä bit ratella (>320 kbit/s tjsp.) jo lähes PCM:n tasolla niin ei sitä dataa mahdottomia määriä enempää olisi vaikka käytettäisiin pelkkää FFT:tä optimoituna. Sitä paitsi ei olisi varmaan mikään ongelma rakentaa hybridijärjestelmää jossa olisi mahdollista käyttää joko taajuus- tai aikadomainiin perustuvaa tallennusta ja prosessointia riippuen tarpeesta (latenssi etc.).
 
Jaava
01.06.2015 22:30:48
      Linkitä kirjoitukseen Tulosta  

mhelin: FFT ja iFFT vie kaikista eniten prossutehoja kaikesta DAW DSP prosessoinnista. Jos ne voisi ulkoistaa muuntimille / audio interfacelle ei tarvittaisi mitään välimuunnoksia. Nyt kanavan signaaliketjussa voi olla peräkkäin monta efektiä jotka jauhavat tuota FFT -> prosessointi -> iFFT ketjua edes takaisin. Lisäksi konvoluutiokaiut ja master kompurat. Jos MP3 on riittävällä bit ratella (>320 kbit/s tjsp.) jo lähes PCM:n tasolla niin ei sitä dataa mahdottomia määriä enempää olisi vaikka käytettäisiin pelkkää FFT:tä optimoituna. Sitä paitsi ei olisi varmaan mikään ongelma rakentaa hybridijärjestelmää jossa olisi mahdollista käyttää joko taajuus- tai aikadomainiin perustuvaa tallennusta ja prosessointia riippuen tarpeesta (latenssi etc.).
 
hmm.. miten konvoluutiokaiku toimisi DFTn kanssa? Mä en siis todella tiedä mitä ne nykyään sisäisesti tekee. Nyt kun konvoluutioteoriaa muistelen niin eikös ole niin, että suoran konvoluution voi laskea periaatteessa reaaliajassa, mutta fourier-muunnetusta konvoluutiosta tulee kertolasku, joka pitää tehdä koko pätkälle kerralla? Eli vaikka se on selkeästi simppelimpi laskuoperaatio, käytännön toteutus ei välttämättä toimi reaaliajassa.
 
"Katastrofien ei pitäisi kestää näin kauan, haluan aamiaista!"
mhelin
03.06.2015 09:24:58
      Linkitä kirjoitukseen Tulosta  

Jaava: hmm.. miten konvoluutiokaiku toimisi DFTn kanssa? Mä en siis todella tiedä mitä ne nykyään sisäisesti tekee. Nyt kun konvoluutioteoriaa muistelen niin eikös ole niin, että suoran konvoluution voi laskea periaatteessa reaaliajassa, mutta fourier-muunnetusta konvoluutiosta tulee kertolasku, joka pitää tehdä koko pätkälle kerralla? Eli vaikka se on selkeästi simppelimpi laskuoperaatio, käytännön toteutus ei välttämättä toimi reaaliajassa.
 
Pikaisella googletuksella (dft latency) löytyi studyjä joiden perusteella DFT:llä saisi pienemmän latenssin kuin FFT:llä, mutta et varmaan tarkoittanut tuota. FFT:llä tai DFT:llä tehdään sama homma, eli mennään aikadomainista eli peräkkäisistä sämpleistä (PCM koodatusta) taajuusmuotoiseen esitystapaan. Tuo tehdään pätkä kerrallaan eli ikkunoidusti, mutta viereisillä ikkunoilla on overlappia 50% tai enemmän. VST:ssä taas käytetään omaa puskurointia, ja olettaisin että tuon overlapin vuoksi mikään konvoluutio ei ole täysin reaaliaikaista. Mutta jos FT unohdetaan, niin pelkkää konvoluutiota voidaan tehdä FIR:inäkin (time domain) joka periaatteessa reaaliaikaista mutta kertolaskuja tulee julmetusti (IR:n pituuden verran joka sämplelle). Jos IR muunnetaan taajuusmuotoon ja samoin data pätkittäin (molempien tulos samanpituinen vektori) kertolaskuja tulee vain tuloksen pituuden verran. Tätä metodia sanotaan "overlap-add" metodiksi, tuossa jotain suht. ymmärrettävää selostusta siitä:
 
http://www.dspguide.com/ch18/1.htm
 
Pitäisi varmaan itse koodata jotain plugaria että tuo selviäisi paremmin.
 
Jaava
03.06.2015 14:06:26
      Linkitä kirjoitukseen Tulosta  

mhelin: Pikaisella googletuksella (dft latency) löytyi studyjä joiden perusteella DFT:llä saisi pienemmän latenssin kuin FFT:llä, mutta et varmaan tarkoittanut tuota. FFT:llä tai DFT:llä tehdään sama homma, eli mennään aikadomainista eli peräkkäisistä sämpleistä (PCM koodatusta) taajuusmuotoiseen esitystapaan. Tuo tehdään pätkä kerrallaan eli ikkunoidusti, mutta viereisillä ikkunoilla on overlappia 50% tai enemmän. VST:ssä taas käytetään omaa puskurointia, ja olettaisin että tuon overlapin vuoksi mikään konvoluutio ei ole täysin reaaliaikaista. Mutta jos FT unohdetaan, niin pelkkää konvoluutiota voidaan tehdä FIR:inäkin (time domain) joka periaatteessa reaaliaikaista mutta kertolaskuja tulee julmetusti (IR:n pituuden verran joka sämplelle). Jos IR muunnetaan taajuusmuotoon ja samoin data pätkittäin (molempien tulos samanpituinen vektori) kertolaskuja tulee vain tuloksen pituuden verran. Tätä metodia sanotaan "overlap-add" metodiksi, tuossa jotain suht. ymmärrettävää selostusta siitä:
 
http://www.dspguide.com/ch18/1.htm
 
Pitäisi varmaan itse koodata jotain plugaria että tuo selviäisi paremmin.

 
Juu siis meinasin yleisesti. FFT on DFT implementaatio. Siis kaikki tuo on mulle täysin selvää (on mulla jotain ~15-20 opintopistettä digitaalista signaalinkäsittelyä opiskeltuna yliopistotasolla kuitenkin). Meinasin, että miten käytännössä toteutettaisiin konvoluutiokaiku taajuustasossa ilman, että latenssia tulee vähintään sen IRn pituuden verran? IRt äänen kanssa työskennellessä yleensä on aika pitkiä. Laskujahan siinä tosiaan olisi pirun paljon vähemmän, mutta taitaa noi konvoluutiokaiut olla aika raskaita prosessoitavia nykyään.
 
"Katastrofien ei pitäisi kestää näin kauan, haluan aamiaista!"
jeraki312
03.06.2015 15:42:55 (muokattu 03.06.2015 15:44:51)
      Linkitä kirjoitukseen Tulosta  

Konvolaatiokaiku, implementaatio, overlappi, FFT, DFT, IR, FIR, kertolaskujen laskeminen, vektori, muunnos, latenssi... "konvolaatiokaiun toteuttaminen taajuustasossa"...
 
Huh huh! Mitä ihmeen rakettitiedettä täällä oikein käsitellään? :D
 
saastara
03.06.2015 16:03:10 (muokattu 03.06.2015 16:04:06)
      Linkitä kirjoitukseen Tulosta  

jii-koo: Konvolaatiokaiku, implementaatio, overlappi, FFT, DFT, IR, FIR, kertolaskujen laskeminen, vektori, muunnos, latenssi... "konvolaatiokaiun toteuttaminen taajuustasossa"...
 
Huh huh! Mitä ihmeen rakettitiedettä täällä oikein käsitellään? :D

 
Noh, ei noi miljoonien huithapeleiden ja taitelijaluuskien käyttämät plugarit ja softat pelkällä pyhällä hengellä maailmaan ilmesty. Jonkunhan tota 'turhaa paskaa' pitää myös pyöritellä.
 
"As long as there is music I am immortal and I have lived forever if I can remember a song"
PIM
03.06.2015 16:18:44
      Linkitä kirjoitukseen Tulosta  

jii-koo:
 
Huh huh! Mitä ihmeen rakettitiedettä täällä oikein käsitellään? :D

 
Rakettitiede taitaa olla lasten leikkiä tämän rinnalla.
 
Kamaahan on sopivasti, tilaa vaan liian vähän.
Pauli Lappalainen
03.06.2015 16:22:13
      Linkitä kirjoitukseen Tulosta  

PIM: Rakettitiede taitaa olla lasten leikkiä tämän rinnalla.
 
Odottakaapas kun nämä signaaliteoreetikot ryhtyvät matemaattisesti asioita todistelemaan. Siitä syntynee yhtälö poikineen.
 
Ostakaa jotain. Jos hintapyyntö ei miellytä, niin tee tarjous.
Hanok
03.06.2015 17:32:41 (muokattu 03.06.2015 17:33:39)
      Linkitä kirjoitukseen Tulosta  

Eikös tuo aika-alueen ja taajuusalueen kysymys koske aika montaa muutakin efektiä, kuin niitä jotka käyttävät konvoluutiota? En tuota tekniikkaan ihan tarpeeksi hyvin tunne, mutta eikö erilaisia viiveeseen perustuvia efektejä, esim. modulaatiot ole tehokkaampi tehdä nimenomaan aika-alueessa?
 
Eli molempia tarvitaan audion prosessoinnissa. Jos muuntimet puskevat Fourier-muunnettua signaalia, niin sitten osa plugareista muuntaa niitä aika-alueeseen ja takaisin? Eivät kai kaikki EQ:tkaan perustu taajuusalueen puukotukseen, vaan tehdään "perinteiseen" tapaan ihan PCM:n filttereillä (mallintamalla oikeinta, tosimaailman filttereitä)?
 
No, tuossa yksi kirjoitus, joka tukee tuota ajatusta. En nyt kuitenkaan ehdi just tähän hätään tarkemmin tutkia ovat nuo pointit kuinka valideja:
http://blog.bjornroche.com/2012/08/why-eq-is-done-in-time-domain.html
 
Jaava
03.06.2015 23:32:22 (muokattu 04.06.2015 00:30:12)
      Linkitä kirjoitukseen Tulosta  

jii-koo: Konvolaatiokaiku, implementaatio, overlappi, FFT, DFT, IR, FIR, kertolaskujen laskeminen, vektori, muunnos, latenssi... "konvolaatiokaiun toteuttaminen taajuustasossa"...
 
Huh huh! Mitä ihmeen rakettitiedettä täällä oikein käsitellään? :D

 
Kiva kun kysyit. Selitetään.
 
Konvoluutiokaiku on semmoinen kaiku, joka on toteutettu laskemalla signaalin ja jonkin impulssivasteen konvoluutio. Usein se impulssivaste voi olla esimerkiksi tilan sointi impulssimuotoisen heräteäänen jälkeen.
 
Implementaatio meinaa sitä kun otetaan joku periaate ja keksitään, miten se toteutetaan käytännössä.
 
Overlappi meinaa sitä kun asiat menee toistensa päälle.
 
FFT on se algoritmi, joka laskee käyrää esimerkiksi taajuusanalysaattoria varten. (t.s. muuttaa sen signaalin aikatasosta taajuustasoon)
 
IR eli impulssivaste on järjestelmän vaste impulssimuotoiselle herätteelle.
 
FIR on filtteri, jolla on äärellisen mittainen IR.
 
Kertolaskuja lasketaan siten, että otetaan luku ja toinen luku ja lasketaan toista lukua sen toisen luvun osoittaman määrän verran yhteen. Tai jotain sellasta ne ala-asteella kertoi.
 
Vektori on sellainen otus, jossa on useampi muuttuja yhdessä kivassa ketjussa. Jos vähän matemaattisempia ollaa niin N:n mittainen vektori on N ulotteisen avaruuden alkio, mutta tässä tapauksessa sillä tarkoitettiin vaan jonoa arvoja.
 
Muunnos on semmoinen, jolla muutetaan jokin asia joksikin toiseksi asiaksi.
 
Latenssi on järjestelmän herätteen ja vasteen välinen aika.
 
Rakettitiede tiivistyy rakettiyhtälöön, joka on ihan simppeli laskettava. Paitsi jos pitää ottaa huomioon gravitaation muutos raketin noustessa. Se tekee siitä paljon paskamaisemman.
 
Noniin. Kaikki on nyt selvää.
 
"Katastrofien ei pitäisi kestää näin kauan, haluan aamiaista!"
Sotahippi
10.06.2015 16:57:52
Musiikkinäyte       Linkitä kirjoitukseen Tulosta  

Näiden teknisten argumenttien oheen on hyvä lisätä semmoinen pointti, että tulevaisuuden arkeologit varmasti osaavat arvostaa korkeampia näytetaajuuksia, että niin isolla vaan kun lompakko kestää. Miettikää millaiset näytetaajuudet/formaatit on käytössä vuonna 5023. Ja koskaan ei tiedä mitä käyttöä tulevaisuus tuo tullessaan millekin formaatille. Siksi tallennus aina maximaalisella teknisellä laadulla. Eikö olisikin kiva, kun jonkun Marilynin elokuvan tekijä olisi käyttänyt isompaa filmiä, jossa enemmän hiukkasia (pixeleitä) per ruutu? Nyt meillä olisi Marilyn in 4k.
Itse rajoitin käynnissä olevan projectin 48kHz:iin kun adatissa on semmoinen rajoitus että max 24bit/48kHz, tai kanavamäärä puolittuu. Vielä en ole mitään adatin kautta siirtänyt mutta onpahan standardin mukaista. ;)
Mutta jos lopputulos on paskan kuuloinen, se ei kuitenkaan johdu näytetaajuudesta. Että sikäli valinta ei ole niin tärkeä.
 
Todellisuudessa ei ole ristiriitoja.
« edellinen sivu | seuraava sivu »
1 2 3

» Lisää uusi kirjoitus aiheeseen (Vaatii kirjautumisen)

Keskustelualueet «
Haku tästä aiheesta / Haku «
Säännöt «