Helvetes Forgård...
- Trådstarter H.R
- Startdato
Diskusjonstråd Se tråd i gallerivisning
-
Takker for det.
dette er første runde av ventehøyttalere. De krever sub men det har man heldigvis. Disse skal beholdes for å brukes igjen i et riktig rom.
Gutta dine er neppe så interessert i dra damer.
Jeg hater å måle - virkelig - dette er noe av det kjedeligste jeg vet. Så begynte å rote meg inn i hva en kan gjøre med API tilgang. Rew har et slikt. Motu har et slikt, og de fleste DAW har et slikt. Det begynte som det alltid gjør - man starter og ser på mulighetene, kommer til en blindvei og må over noen gjerder. Det er mange blindveier og gjerder..... Så nå har ting endret seg fra å bare måle til å lage et system som kan måle, analysere og optimalisere et aktivt høyttalersystem ved hjelp av REW, DSP-kontroll og AI-assistert analyse. Tanken er ikke at AI-en skal gjette seg frem til løsninger, men at den skal analysere faktiske målinger opp mot kjent akustisk teori og dokumentasjon fra blant annet REW.
I stedet for å bruke en tradisjonell DSP-enhet programmeres signalbehandlingen direkte i VST-plugins. Etter å ha møtt veggen utallige ganger fant jeg ut det var enklere å lage et VST plugin som har alt jeg trenger. Gain, delay, mute, fase, XO og EQ. Et felles tilgangspunkt som jobber med meg og ikke mot meg. Filtere, delay, gain, polaritet og annen signalbehandling styres automatisk og skrives direkte til pluginene. På den måten kan man bygge svært avanserte aktive delefiltre og DSP-løsninger uten å være bundet til spesifikk maskinvare. Siden jeg virkelig hater lukkede systemer så kan jeg eksportere data fra plugin til bla Pro-Q, få ut alle verdier som plugin holder og bruke de som jeg vil. Dette er nyttig siden jeg liker å se hva som skjer.
Parallelt jobber jeg med en egen lydmotor som på sikt skal fungere mer som en integrert del av Windows enn som en tradisjonell DAW. Tanken er at den skal kjøre som en tjeneste i bakgrunnen, omtrent som en driver eller systemtjeneste, slik at hele DSP-kjeden alltid er tilgjengelig uten at man må ha et DAW-program åpent. Målet er å kombinere fleksibiliteten fra studioverdenen med brukervennligheten til en dedikert DSP-prosessor.
Systemet måler driverne separat og analyserer blant annet:
- frekvensrespons
- fase
- impulsrespons
- group delay
- summering
- invert-null
- kanalbalanse
- timing og delay
En ting jeg synes mangler i mange automatiske løsninger er at de prøver å løse alt med EQ. Derfor er det også bygget inn logikk som vurderer om et problem faktisk skyldes høyttalerplassering eller rommet. Dersom systemet ser tydelige avvik mellom høyre og venstre side kan det foreslå å flytte en høyttaler, ta nye målinger og sammenligne resultatene før det begynner å korrigere med DSP.
I tillegg forklarer systemet hva det gjør underveis på et språk som er forståelig uten at man trenger å være REW-ekspert. Målet er at brukeren skal forstå hvorfor en løsning ble valgt, ikke bare få et resultat fra en svart boks.
Romkorreksjon er heller ikke tenkt løst av systemet alene. DSP-optimalisering av drivere og delefiltre skjer først, mens romkorreksjon kan legges på som et eget lag etterpå. Her fungerer ARC X svært godt og er derfor tenkt som en integrert del av løsningen for den siste finpussen mot lytteposisjon.
Det som kanskje er mest interessant er at systemet bygger opp historikk over tid. Jo flere målinger som gjøres i det samme rommet og på det samme anlegget, desto mer datagrunnlag får analysen. Da kan den etter hvert kombinere generell akustisk teori med erfaringer fra akkurat det rommet og det oppsettet. Målet er at analysene skal bli mer treffsikre over tid og at man skal trenge færre målinger for å komme frem til gode løsninger.
Prosjektet kommer i havn. Det bekymrer meg egentlig ikke. Da jeg startet var AI-modulen helt tom. Den er fortsatt laget med én oppgave: å analysere data og forklare resultatene på en menneskelig måte. Den bygger ikke på generell kunnskap eller ferdige fasitsvar, men på erfaringene den selv samler gjennom systemet den brukes i.
De siste dagene har jeg kjørt rundt 2000 målinger i døgnet for å lære opp systemet. Målet har vært å forstå hva REW faktisk måler, hvordan parameterne henger sammen, og hvordan de bør tolkes opp mot det som beskrives i dokumentasjonen. Samtidig lærer systemet mer om rommet det brukes i. God plassering av høyttalere kan ofte redusere behovet for DSP, og siden mer DSP gir lavere score i modellen, er dette en viktig del av optimaliseringen.
Mens maskinen har jobbet har jeg fått gjort helt andre ting. Jeg har klippet plenen, vasket kjøkkenet og kjørt flere lass til gjenvinningsstasjonen. Systemet står i praksis og lærer mens jeg gjør noe annet.
Nå begynner det å bli mye data, og jeg har fått på plass gode skript for å analysere de fleste parameterne. Selv om det fortsatt er langt igjen, har prosjektet passert proof-of-concept. Utfordringen er ikke lenger å få systemet til å fungere, men å få det til å måle smart. De fleste målingene så langt har egentlig handlet om å finne ut hvilke parametere som betyr noe, hvilke som betyr lite, og hvordan de bør vektes mot hverandre.
Grunnideen er enkel: parameterbasert scoring. Brukeren skal selv kunne velge hva som er viktig og hvordan ulike kriterier skal vektes. I stedet for å sitte og tolke et stort antall grafer, får man presentert de fem beste kandidatene sammen med en forklaring på hvorfor akkurat disse løsningene scorer høyest.
Om dette noen gang blir et produkt som kan distribueres, handler det først og fremst om investeringsvilje. Flere av bibliotekene som brukes i dag er gratis så lenge prosjektet er privat, men krever kommersielle lisenser dersom det skal selges. Som en som lever på statlig apanasje er ikke det nødvendigvis et naturlig neste steg.
Prosjektet har også tvunget fram noen tekniske valg. Erfaringen med plugins og komponenter som ikke lenger vedlikeholdes gjorde at jeg til slutt skrev en helt ny kontroller for lydkortet. I dag benyttes kun offisielle eller åpne grensesnitt: Roon sitt API mot Roon, REW sitt API mot målesystemet, OSC mot DAW-en og JSON-baserte grensesnitt mot lydkortet.
Frontend bygges med Blazor, noe som gjør det enkelt å lage dynamiske løsninger for mobil og nettbrett. Det åpner for at brukere kan få tilgang til egne soner og funksjoner uten å få tilgang til selve kjernesystemet. Målerutiner og avanserte funksjoner kan beskyttes med PIN-koder.
Et langsiktig mål er full plattformuavhengighet. I dag kjører DSP-delen på en Mac i et lukket system, men for å kunne bygge og distribuere installasjonspakker på en god måte trengs det etter hvert en nyere Mac Mini.
Når alt kommer til alt er prosjektet drevet av to ganske enkle behov. Det ene er å gjøre DSP-løsninger enklere og mer intuitive i daglig bruk. Det andre er at jeg egentlig ikke er spesielt interessert i å bruke tiden min på å måle. Derfor prøver jeg å bygge et system som kan gjøre mest mulig av den jobben selv, og samtidig forklare hvorfor det velger løsningene det gjør.
Det er kun kolonnene som er på høyre side som er i drift. Programmet her viser hva som skjer, hva man gjør og prosessen da det ikke er meningen å måtte forholde seg til alt som skjer, men få hovedtrekkene forklart. Målet her er at AI banken skal fylle seg opp og bruke rew sin online manual for å forklare enkelt hva som egentlig skjer.
En ting jeg har begynt å tenke mer og mer på er at det ikke nødvendigvis er så viktig å beskrive hele rommet i detalj for å forstå hvordan anlegget oppfører seg i et logisk rektangel/triangel En vanlig stue er sjelden firkantet. Det er møbler, bord, åpninger, vinkler og andre ting som gjør at det fort blir veldig komplisert dersom man skal forsøke å modellere alt.
I stedet prøver jeg å ta utgangspunkt i det som faktisk betyr noe for lyttingen, nemlig forholdet mellom høyttalerne og lytteposisjonen. Disse tre punktene danner et lyttriangel, og rundt dette etableres et logisk rektangel som systemet bruker som analyseområde.
Tanken er å måle i hjørnene av dette rektangelet, langs sidene og i punkter knyttet til lyttriangelet. På den måten får systemet et sett med referansepunkter som er enkle å gjenta og sammenligne over tid. Målet er ikke å kartlegge hver eneste detalj i rommet, men å bygge opp en forståelse av hvordan rommet oppfører seg der det faktisk har betydning for lyttingen.
Særlig under Schrøder-frekvensen er rommet ofte den dominerende faktoren. Ved å måle på disse faste punktene kan systemet gradvis danne seg et bilde av hvordan energi fordeler seg i rommet, hvor rommodene påvirker mest, og hvordan høyttalerplassering og lytteposisjon samhandler med rommet.
Etter hvert som det samles flere målinger fra det samme rommet kan systemet begynne å se mønstre. Kanskje en bestemt plassering alltid gir bedre symmetri mellom kanalene. Kanskje et område konsekvent gir en dip eller topp ved en bestemt frekvens. Kanskje en liten flytting av høyttalerne gir større gevinst enn omfattende EQ.
Grunnen til at jeg ønsker å gjøre det på denne måten er at mange løsninger hopper rett til korrigering. Jeg er mer interessert i å forstå hvorfor et problem oppstår før jeg prøver å rette det. Hvis årsaken er plassering eller romgeometri er det ofte bedre å løse det der først, og bruke DSP og romkorreksjon til finjustering etterpå.
Målet er derfor ikke å lære hvordan rommet ser ut i detalj, men å lære hvordan rommet oppfører seg sammen med akkurat dette anlegget. Jo flere målinger systemet får over tid, desto bedre blir forståelsen av hva som faktisk fungerer i akkurat det rommet. Da kan systemet etter hvert bruke både generell akustisk teori og erfaringer fra tidligere målinger til å gi mer presise forslag enn det en enkelt måling i lytteposisjon kan gjøre alene.
fant ut at det er for snevert å basere ai modellen til kun rew sin hjelp
Så nå er det implementert oppslag mot.
REW Help
Engineering Acoustics
Understanding Acoustics
Ai modellen er også kategorisk til å støtte seg til faktisk måling og oppslag til kjent teori. Siden modellen kjører lokalt så er det også lett å sette den til å bruke kildebasert kunnskap fremfor å klø meg på ryggen og si dette er bra når målingene sier annerledes.
Målet er å forstå hvorfor ting måleravvikende mellom kanaler, om det skjer, støtte seg til kjent teori og deretter informasjon om mulige veier. Man kan selvsagt ignorere alle råd og kjøre på, men igjen, dersom man kan plassere seg ut av uføret så er det å foretrekke fremfor å kjøre hard dsp bruk uten å egentlig gjøre annet en å flytte et problem. Dersom romnoder gjør at det alltid vil være problemer i et gitt område så skal dette området ikke korrigeres.
for å løse det under schrøder så vil systemet måle om man har to subwoofere som auto. Dvs først som stereo høyre og venstre, men også som dual mono og gå videre med det som summerer best i rommet fremfor å velge en løsning man har lyst på men som ikke virker like godt. Følelser har lett for å komme i veien for fornuften tross alt.
Hvor langt har jeg egentlig kommet?
Lenger enn jeg hadde trodd da jeg startet, og samtidig ikke i nærheten av ferdig, for programmet i seg selv samler data, historikk, forsøk. Kanskje fra disse høyttalerene, kanskje fra andre. Men systemet samler, strukturerer og ser på tvers av oppsettene som er innom rommet.
Det som kanskje har overrasket meg mest er hvor mange antakelser som har blitt utfordret underveis.
For en stund siden mente systemet at 429 Hz var det beste delingspunktet mellom mellombass og mellomtonehorn. Det så fornuftig ut på papiret og scoret bra på flere av parameterne som ble vurdert. Jeg ble selvsagt imponert over valget, for det virket svært presist. Med en sannsynlighet på hele 79.1% over er godt resultat tenkte jeg alt var i boks.
Problemet var bare at etter hvert som flere målinger, analyser og verifiseringer kom til, begynte bildet å endre seg. Selv om 429 Hz så bra ut isolert, viste det seg at integrasjonen mellom driverne faktisk ble bedre rundt 454 Hz. Ikke dramatisk bedre på én enkelt måling, men konsekvent bedre når hele beslutningsgrunnlaget ble vurdert.
Det samme har skjedd i toppen. Der har systemet etter mye testing og verifisering landet på 6757 Hz ,jeg ba den finne i et område mellom 7 og 12000. Likevel så kom 6757 frem med som det mest fornuftige delingspunktet mellom horn og diskant. Ikke fordi det er et pent tall, men fordi det ser ut til å gi den beste kombinasjonen av faseforhold, summering og integrasjon.
Hadde jeg satt meg ned med REW og gjort dette manuelt? Neppe.
Hadde jeg hatt tålmodighet til å teste hundrevis eller tusenvis av kombinasjoner rundt disse områdene, analysere dem opp mot hverandre og deretter gå tilbake og verifisere funnene flere ganger? - ikke en snøballs sjanse i helvete.
Og det er egentlig her jeg begynner å se verdien av prosjektet.
Maskinlæringsdelen erstatter ikke ørene mine, den erstatter ikke teorien og den erstatter ikke målingene. Men den har en arbeidskapasitet som er fullstendig urimelig sammenlignet med et menneske, og en egenutviklet ai modul passer på. Den tar ikke valg basert på følelser men basert på kilder og historikk.
Den blir ikke lei. Den blir ikke utålmodig. Den bestemmer seg ikke for at “430 Hz er sikkert nærme nok” fordi klokka er blitt halv ett om natta, ikke skal den se vi på fotball heller, blir ikke full og er lydig som en godt trent sauehund. , den jobber, tar ingen snarveier, tester analyserer og samler data for å finne en kombinasjon som henger sammen på en måte jeg aldri hadde giddet, og blir flinkere over tid når datagrunnlaget øker.
Den bare fortsetter å teste hypoteser til den finner ut hva dataene faktisk peker mot.
Det mest interessante er kanskje ikke at den finner svarene. Det mest interessante er at den av og til motbeviser ting jeg selv var ganske sikker på.
Det begynner å bli vanskelig å argumentere med en maskin som har sett flere målinger av anlegget mitt på en uke enn jeg har sett til sammen i mitt liv.
Jeg har fått første måling basert på denne metoden. Jeg holder nå på med å teste alle beslutninger opp mot rew, sjekke alle felter at den regner likt i pluginet og i dsp modulen. For arsenalet består ikke lenger av masse peq punkter, men implementerer alle metoder som er beskrevet her. https://www.w3.org/TR/audio-eq-cookbook/
Det er ok dessverre er godt stykke igjen før det kan skje gutman. Mye må verifiseres og det står på investering og der har jeg ikke så stort armslage etter jeg ble tatt ut av arbeidslivet. Er på stadie hvor jeg er fornøyd om jeg fremdeles har mat på bordet etter at alle regninger er betalt. Men det er fascinerende å se hva som er mulig å få til for en utdatert systemutvikler og at det går an å strukturere prosesser med moderne teknologi.
Da er en ny full test gjennomført.
Et av de mer interessante resultatene så langt er at fase, delay og kanalintegrasjon ser ut til å være godt under kontroll. Til tross for et rom med ganske kraftig asymmetri opprettholder systemet et presist og stabilt stereobilde, noe som tyder på at de største utfordringene ved lytteposisjon i stor grad er håndtert og det vesentlig bedre en jeg ville fått til.
så da kan jeg endelig begynne å jobbe med rapporteringsfunsjoner, visuell som tekst. Eksport av alle data over oppsettet til tekstfiler slik at ting er transparent og teste at apiet sender samme data til en dumpfil slik at man kan sende data direkte til andre løsninger om jeg skulle få brukt for det. Greit å teste når det faktisk er noe å teste før en utvikler resten av prosjektet.
Håvard har en hjerne som på enkelte områder ligger flere plan over gjennomsnittet her på sentralen.
Hva det sier eller betyr for oss andre her, har ikke jeg noe lyst å utdype, heller ikke mene noe om.
Var en kjapp tur innom casa Jessheim i kveld ifm. øvelseskjøring med kjerringa.
Her er en slem setup, med hjemmelaget DSP løsning som ikke finnes noe annet sted.
Det låter bedre nå enn da jeg sist var her.
Dette må du gå videre på Håvard, og jeg håper du kan få laget til noe som flere av oss her kan få glede av ta i bruk etterhvert.
Herfra til sluttbruker og kostnad er vel en vei videre i ukjent terreng foreløpig
Men jeg gir tommel opp så langt.
Hva gjør man når ting ikke virker som man selv mener det bør virke? Man lager det selv.
Siden jeg generelt liker at ting bare fungerer, er lett å vedlikeholde og ønsker at ting skal være lett å sette opp så bestemte jeg meg for å lage en egen DAW med matix. Dette som en egen service med et micro applikasjon som tillater en å få tilgang til mikrofonen i sikkerhetsinstillingene på maskinen. Det er flere grunner til det. Ene er at den kunne utvikles som en bakgrunnsservice til en gammel mac mini fra 2014 som har en eneste oppgave. Å kontrollere lydkortets DSP, lett bruk mao. Foreløpig har jeg ikke inkludert romkorreksjon pluginet da jeg må ta dette stegvis uten å miste kontrollen.
Jeg hadde jo allerede kontroll på komunikasjonen mot REW for å sette alle variabler til et VST plugin, så fremfor å bruke plugin så styres dette nå direkte i en service på mac'n
Så da får man input, men en irritasjon er jo at jeg ønsker ikke nødvendigvis å bare binde meg til en input, mer om det
Ved å kunne ha forskjellig input og output device åpner det seg for nye muligheter.
Siden Blackhole testen fungerer fint så blir det å lage virtuelle drivere til
Roon, Spotify og evt andre. Navnet skjemmer ingen og eneste forskjellen er navnet. Disse kan routes direkte til daw sin bus og de trenger lenger ikke inn i lydkortet siden jeg kan ta de via egne drivere.
Volumkontroll blir også like gjerne satt her - noe som sparer meg for mye arbeide ved å vedlikeholde Motu koblingen - men siden jeg vil sjekke med motu hvordan de har implementert volumkontrolleren, jeg mistenker digitalt, men skulle det være analogst så vil jo en link til dette være lett å sette opp.
Routingen er også enkel. Siden jeg allerede har konfigurert rew til å faktisk måle, så henter jeg innstillingene fra rew og setter dette i lydkortet, og jeg husker enda 3 minutter så jeg kan være klok å sette disse til det samme som i Arc X.
Inputs - jeg tester med 4 og outputs har jeg jo ikke mer en 8 av er rimelig enkelt å sette opp, for dette gjør jeg samtidig som jeg setter opp måleoppsettet i rew.
For ekstra input fra lydkortet så vil det komme flere - basert på inputs som er mulig å forholde seg til + roon og spotify.
Roon koblingen lager et plugin som holdes av daw slik at aktiverer man roon så aktiverer man plugin. Enkelt og greit.
Spotify krever nok litt mer arbeide siden der kan man ikke sette 48khz som egen output så der får en resample i selve core audio virtual driveren basert på hva output er satt til i lydkortet.
Selve navigeringen mellom alle flater gjøres via blazor apps som deler de data de trenger å dele.
Selve hjernen er core som passer på backup av alle seksjoner som er i bruk slik at man kan restore de der man skal bruke de senere. For har man først lært opp systemet i ML modulen så er det jo litt kjedelig å starte på scrach på opplæringsfronten da den vil fortsatt benytte vesentlig mer tid en runde 2 eller 3.
Jeg spiller på dette nå - og ting virker tilsynelatende som jeg forventer.Sist redigert:
volumkontrolleren i daw .
funksjonen er enkel - man måler alle kanaler i matrixen og dersom en av de når problematisk område så justeres max volum basert på det som faktisk spiller dynamisk fremfor å sitte med hjerte i halsen når det er fest.
Selve volumkontrollen vil bli en surface dial siden jeg har en slik. Den vil ha vanlig funksjon som volum, kildebytte og play pause i roon.
Fått koblet til Surface dial til macen og linket den opp til DAW via en service jeg laget for å omdanne dataen som dial sender.
Nå kan en endre volum fra dial selv uten å ha vinduet oppe - det er noe befriende når ting ikke er supportert i OS og en kan forbigå alt som står i veien.
Nitidig arbeide, bare det å få responsen til å bytte for så å holde flere ticks når den er i et kanalskifte krever at en faktisk sier at den skal gjøre det. Men det fine er at nå virker det mot roon, Nytt roon plugin er laget som genereres fra DAW, laget ny core audio virtual driver for å la Roon sende direkte til daw fremfor at en går gjennom lydkortet først.
neste ut er å lage en Spotify core audio, som jeg kan linke spotify til - da vil den kunne sende signaler til daw og en får dette opp som egen kilde.Dette er en funksjon jeg egentlig har savnet i eksisterende daw, siden routing av signaler inn fra kilder som forventer å sende alle til kanal 0 og 1 skaper alltid problemer for instans nummer to. Nå lager jeg bare en egen service til hver instans og kan paralellkjøre de inn i løsningen.
Så nå står surface dial, daw, lydkort, målesystem med rew på en og samme mac mini fra 2018 og den spiser ikke opp ressurser.
Siden visningen kan spittes opp er det ingen problem å ha surface dial nå på macen, vise ting på en pc, ipad eller annen webleser og en får frem menyene der man vil med kontroll fra et sted.
Gutman har lyst på en egen variant av visningen, jeg gjetter på intens AI bruk for generering av denne visningen men hva vet vel jeg? Paint kan jo være oppdatert siden sist jeg brukte det.
noe som faktisk er mulig selv om knapper og brytere egentlig bare er en skjer og om man finner seg en slik skjerm og bruker litt tid på å få den til å vise ting som vi ønsker, skjermer er tross alt hyllevare og de må jo ikke være i en utforming som selges på elkjøp tross alt.
ja - krever ikke mye ressurser i bruk så det holder i massevis når en ikke trenger å utvilke på den. Da går timene fort i ventetid
Laget en enkel oversikt over de servicer som faktisk brukes.
Siden spesielt spotify spiller til default så har jeg laget et endpoint som kan benyttes og sender via virtuelle drivere rett inn til daw.
Qobuz er enklere for den kan velge hvilke kilde man skal sende til så der velger man bare rett source. Roon er allerede under kontroll så der slipper jeg å gjøre annet en å fintune pakken til å spille feilfritt, men for det så har jeg satt på en del logger som faktisk viser alt det som skjer i driveren. Har man ikke roon, så har jeg laget en driver også for LMS som er et gratis godt alternativ.
Hver av disse går inn i daw bus og om de er aktivert som kilde så vil man kunne bruke disse. Siden man ikke skal bryte noen regler så vil webplayer fra Qobuz være ganske grei siden den tillater at man tar hele grensesnittet inn i egen frame på en nettleser, men for spotify er ikke dette tilfellet. Da må man bygge opp at man får visuelle flater over hva som spilles som cover, artist, sang og det som har relevans. Alle disse visningene er visninger - man må fremdeles velge hva man spiller i qobuz, spotify, roon og LMS i deres grensesnitt, men vi kan tillate å faktisk vise hva som skjer uten å bryte noen regler.
Håpet er at at Spotify skal kunne eksponere JAM på en måte at man kan ha en fast klient men jam funksjonen kan aktiveres der. Slik er det ikke nå.
Etter å ha brukt timer på å lage gode prober for å overvåke under runs, dvs pakke tap så fant jeg et buffer som pakket seg opp. Normalt skal ikke slikt skje men feilkoding skjer og det er lett å overse ting. Nuvel. Nå er det endelig på tid å sjekke stabilitet og det gjøres flere steder. En i core audio, en i daw input og en i daw output. Her skal det ikke være feil. La også opp en probe som sjekker cpu, minne og disk og skriver en log for hver 60 sekund for å se at ting ikke bygger seg opp over en langtidstest. Er det ikke stabilt i 12 timer så må det løses. Jeg har allerede laget en rutine som restarter services automatisk om det ikke er signal inn på daw over en periode på 30 minutter fra et intervall 4 ganger i timen. En service stopp og start er under 1 sekund og jeg mener det er en svært begrenset ulempe fremfor å måtte ta omstarter. Det siste en vil er at minne eller cpu skal øke over tid.
DAW ser stabil ut. Det er logget 500 målepunkter fra ca. 00:02 til 08:35, uten feilprøver.
Viktigste tall:
- NeuronDAW minne: startet ca. 261 MB, nå ca. 133 MB
- DAW minneområde: 108-261 MB
- Ingen tegn til minnelekkasje i DAW så langt
- DAW CPU snitt: ca. 4.4 %, maks 10.2 %
- Underflows: startet på 2, står fortsatt på 2
- Overflows: 0
- Audio engine: running
- Input og output har signal
coreaudiod: minne stabilt rundt 38 MB, men CPU rapporteres høyt i MacAgent, snitt ca. 81 %. Dette må vi følge, men det er ikke en minnelekkasje.
- RoonBridge: helt stabilt rundt 90.7 MB
- RAATServer: stabilt, ca. 57.1 -> 58.2 MB
- Surface Dial: lavt forbruk, ca. 4.5 -> 9.6 MB
- Node-tjenestene: ingen klar lekkasje; den største gikk ned fra ca. 211 MB til 128 MB
Etter litt polering så ser daw sitt vindu ganske så ryddig ut.
Om man ønsker å kilde rett fra daw så trykker man på den knappen som måtte være her. For volum så kan man ha og lagre hvordan man vil vise det.
Manuell slider og hva som har skjedd i controlleren. Følsomheten til surface dial velges også her og man får en visuell oversikt over følsomheten på hjulet
Man setter opp lydkkortet gjerne en gang og binder det opp til daw. Ingen grunn til å vise dette mer en nødvendig.
I profil finnes kun to profiler. En for måling og en for avspilling.
Når man setter måleprofil så vil en sette hvor mikrofonen er koblet til på lydkortet samt hvilke kanaler man skal lytte til for måling. I tillegg settes loopback kilden som brukes i rew. Når en skal måle skrus alle steder man man endre data av, slik at systemet jobber med et "låst" system uten påvirkning fra surface dial eller annet.
Kilder sorteres etter hva som er aktivt, rekkefølge på navigeringen og tilgjenglige kanaler som er valgt som input.
Disse er default lukket for enklere sortering men her setter man hvilke input kanaler disse skal ha.
Hver går automatisk til en bus, som er en kanal som selve DAW lytter til. Der muter eller unmuter man bus slik at man ikke får lyd fra flere kilder. Kun en bus kan være åpen av gangen.
I Output mapping setter man hvilke fysiske kanaler som er i bruk og viser hvilke xo som er i bruk.
Alle felter vil bli hentet opp fra når en måler og satt automatisk slik at man ikke trenger å sette dette mer en en gang.
Nå jobbes med backup av instillinger, at man får et sett med data som kan aktiveres på en annen datamaskin dersom DAW blir flyttet til en annen datamaskin.
Målet er å ha et flytende oppsett for alle instanser slik at man ikke blir bundet til at man bruker nettopp den maskinen senere. Hardware byttes og da må man enkelt kunne sette ting opp med de instillinger som kan resiruleres.
Etter backup blir det å lage en service for hver inputkanal som står aktiv. Dette øker stabilitet - koster lite i form av minne og cpu men reduserer komplikasjoner dersom man skal legge til en ny kildemulighet senere. Da dupliseres kun en hel sti og man får tilgang til denne uten å måtte huske hvordan man laget dette.
Backup vil bli som dette og er komplett.Man skal kunne låse en fil for reclycle slik at man kan gå tilbake til et kjent oppsett. Kanskje man har testet en annen Target og vil kunne sette dette frem og tilbake.
Foreløpig er hele programvaren på engelsk, ikke fordi det er så kult og internasjonalt, men det er lettere å lage en xml fil med norske navn senere en å styre med æøå som tar uforholdsmessig mye tid å holde på med.
Når man rydder kan man like gjerne gjøre det ordentlig så jeg fant ut at jeg kunne forenkle grensesnittet ytterligere og dermed redusere feilkilder til et minimum.
Fjernet muligheten fullstendig fra å kunne justere noe i daw direkte og har heller flyttet ut i logiske grupper til wizard.
Alle wizards er låst med selvvalgt pin slik at det ikke lar seg konfigurere uten.
Når man har gjennomført dette er rew klar til å måle men man må også gå gjennom oppsettet for høyttalere selvsagt. Samme logikk for å sette opp. Et spørsmål, et svar.
Når dette er gjennomført så vil alle kanaler være mutet siden det ikke finnes noen safe route så man vil i dawfå varsel om at lyd ut er blokkert.
Det er helt korrekt adferd da man har ikke målt og dermed satt opp systemet som helhet.
Etter gjennomført måling og dermed også gitt alle utgangene data nok til å fungere så fylles data inn og systemet kan brukes til å spille musikk.
Brukt litt tid for å trekke skjermkortet inn slik at man får evaluert lenger og ta bedre beslutninger i ML modulen. Så da var det på sin plass å lære den hele rew manualen på nytt, forstå alle API kommandoer og til slutt kunne danne et grunnlag på flere parametere samtidig. Så det medførte at jeg kunne allokere datakraft på en mer rasjonell måte og ta i bruk asynkron tjenester. Det starter med en serie målinger og hver måling blir lagret eller forkastet avhengig av kvalitet på målingene. Deretter så begynner jo den nitidige nåla i høystakken. Hva er rett, hva er lurt. Hvor er det best egnet å gjøre noe og hva er kostnaden med nettopp dette valget.
Optimaliseringsalgoritmen skal ikke kun optimalisere mot frekvensrespons eller lokal summering. Den skal være en flerobjektiv optimalisering hvor amplituderespons, fase, gruppedelay, impulsrespons og stereointegritet vurderes samtidig.
Følgende tekniske prinsipper skal ligge til grunn:
* Maksimal fasekoherens mellom venstre og høyre kanal skal bevares gjennom hele signalveien.
* Differensielt gruppedelay mellom kanalene skal minimeres over hele arbeidsområdet.
* Impulsresponsen skal bevares med minst mulig tidsmessig smøring.
* Filtervalg skal gi lavest mulig faseforvrengning samtidig som ønsket amplituderespons oppnås.
* Asymmetrisk EQ, delay eller filtrering mellom kanalene skal kun benyttes når det er dokumentert nødvendig og gir en målbar forbedring.
* Små forbedringer i amplituderespons skal ikke prioriteres dersom de medfører større degradering av fasekoherens, gruppedelay eller impulsrespons.
* Ved flere løsninger med tilnærmet lik amplituderespons skal løsningen med høyest fasekoherens, lavest differensielt gruppedelay og best bevart impulsrespons velges.
* Optimalisering skal utføres på den totale systemresponsen, ikke kun på enkeltparametere isolert.
* Alle optimaliseringstrinn skal evalueres mot en samlet kostnadsfunksjon hvor amplitudefeil, fasefeil, gruppedelay, impulsrespons og kanalkoherens inngår med eksplisitte vekter.
* Ingen enkeltparameter skal kunne forbedres vesentlig dersom dette gir en større samlet degradering av systemets totale ytelse.
* Dersom en endring forbedrer én parameter, men forringer flere andre, skal den totale kostnadsfunksjonen avgjøre om endringen aksepteres.
* Algoritmen skal søke den løsningen som gir høyest samlet teknisk kvalitet fremfor best resultat på én enkelt måleparameter.
Etter en lang dag med opplæring så kan det være at jeg får et resultat basert på disse linjene i løpet av natten. Forrige runde endte i katastrofe mens den før var svært oppløftende. Jeg vet hvorfor den forrige ble så dårlig så da er det greit nok selv om skuffelsen var stor når jeg så rapporten og ikke minst hørte på resultater.
Jaja. Blitt en del ML optimalisering som ikke har gitt ønsket resultat. Så da er det bare å utvide med bedre verktøy, så hentet inn NumPy og SciPy. Forholdsvis kjedelige ting men egner seg godt når en skal få beregnet ting fort i gpu og ta kontroll over utregninger. Datakraften tåler uansett ufattelig mye mer å gjøre for at man skal kunne se at den jobber i oppgavebehandlerem. Det ville være enklere å tvinge frem en forhåndsdefinert xo og tvinge frem delinger med de ulemper som dette gir men dersom dette var målet måtte jeg også akseptere at det er den raskeste måten å oppnå resultat på men neppe den mest optimale.
Mye tekst, men om noen skulle gidde å lese hvordan beslutninger tas pr nå, selv om jeg vet det helt sikkert kommer revisjoner, så er der bare å lese videre. Anser det som et metodedokument som er tungt og kjedelig lesestoff dog og helt uten bilder eller grafer med fjonge fossefall eller annet som bryter med en eviglang tekst.
En deterministisk ML/DSP-motor for høyttaleroptimalisering basert på råmålinger fra REW og beregninger i NumPy/SciPy. Motoren skal finne og verifisere optimalt delepunkt, XO-slope, delay, gain, polaritet/fase, EQ, venstre/høyre-symmetri, romhåndtering, stereosenter og origojustering. ML kan foreslå søkeområder, vekting og strategier, men alle beslutninger skal verifiseres matematisk fra måledata. Motoren skal ikke være en “smart kurveutjevner”; den skal være en etterprøvbar akustisk beregningsmotor.
Grunnregel: Ingen endring skal godkjennes bare fordi frekvenskurven ser penere ut. En kandidat må forbedre eller bevare kompleks summering, fase, invertert null, group delay, headroom, driverstress, forvrengning, powerrespons, L/R-symmetri, stereosenter og origo-konsistens.
- Obligatorisk målegrunnlag
Start alltid med råmålinger uten EQ, uten delay og uten delefilter dersom mulig. Hver driver må måles separat i REW med samme mikrofonposisjon, samme sample rate, samme timing reference og samme gainstruktur. Rådata skal aldri overskrives.
For hver måling skal følgende metadata lagres:
measurement_id, session_id, timestamp, sample_rate, bit_depth, REW_export_type, mic_id, mic_calibration_file, mic_position_id, mic_x, mic_y, mic_z, speaker_side, driver_id, physical_channel, DSP_channel, amp_channel, polarity_state, gain_state_db, delay_state_ms, filter_state, EQ_state, sweep_level_db, estimated_SPL, timing_reference_type, timing_reference_channel, gate_start_ms, gate_end_ms, window_type, smoothing_state, valid_from_hz, valid_to_hz, noise_floor_db, SNR_by_band, clipping_detected, routing_verified, polarity_verified og confidence_score.
Dersom nødvendig metadata mangler, skal motoren redusere confidence eller stoppe automatisk optimalisering.
- Kompleks respons som kjerneformat
Alle beregninger skal baseres på kompleks frekvensrespons:
magnitude_linear(f) = 10^(magnitude_db(f) / 20)
phase_rad(f) = unwrap(deg2rad(phase_deg(f)))
H(f) = magnitude_linear(f) * exp(j * phase_rad(f))
Dersom impulsrespons brukes:
H(f) = FFT{h(t)}
Alle drivere skal interpoleres til felles frekvensakse. Interpolasjon skal gjøres på kompleks respons eller separat på log-magnitude og unwrapped fase. Wrapped fase skal aldri brukes direkte til delay, group delay eller summering.
- Parametre som alltid skal beregnes
For hver driver, hver side og hver fullrange-sum skal motoren beregne:
magnitude_db(f), unwrapped phase, excess phase hvis mulig, group delay, minimum-phase-estimat, excess group delay, impulse peak time, band-limited arrival time, energy time curve, step response, RMS level by band, peak level by band, crest factor, SNR by band, noise floor by band, valid frequency range, direct sound confidence, room dominance confidence, headroom margin, driver stress index og measurement quality score.
Motoren skal ikke anta at impulspeak alene er korrekt akustisk ankomsttid. For hver driver skal det beregnes band-limited arrival time i driverens faktiske arbeidsområde.
- Målekvalitet og forkastingsregler
Før optimalisering skal motoren kontrollere:
routing, kanal-ID, polaritet, sample rate, timing reference, SNR, clipping, impulsstart, fasekontinuitet, gyldig frekvensområde, støy, målevindu/gating og om målingen dekker nødvendig overlapp.
Målingen skal forkastes eller gis lav confidence dersom:
SNR er for lav i overlappet, fase hopper unaturlig, impulsresponsen er trunkert, routing er ukjent, polaritet er ukjent, REW-export er ufullstendig, målingen har clipping, eller frekvensresponsen har hull som ikke kan forklares akustisk.
- Gyldig overlapp og kandidatfelt
For driverpar A/B skal motoren finne gyldig overlapp basert på:
målt respons, SNR, driverens trygge arbeidsområde, forvrengning, direktivitet, powerrespons, membranoppbrytning, horn/waveguide-loading, termisk/mekanisk margin, romdominans og ønsket systemmål.
Kandidatområdet skal ikke bare være der kurvene krysser hverandre. For hver mulig delefrekvens skal motoren analysere et vindu rundt delefrekvensen, typisk ±0.5 til ±1 oktav.
- XO-kandidater
Motoren skal teste:
delefrekvens, filtertype, slope, delay, gain og polaritet.
Minimum filterkandidater:
LR2, LR4, LR8, Butterworth 2/4/8 og asymmetrisk slope der det er akustisk begrunnet.
LR4 er standard startkandidat, men motoren skal velge ut fra målt akustisk resultat, ikke forhåndsvalg.
Filterrespons beregnes som kompleks respons:
H_driver_filtered(f) = H_driver_measured(f) * H_filter(f)
Normal sum:
H_sum(f) = H_A(f) + H_B(f)
Invertert test:
H_null(f) = H_A(f) - H_B(f)
- Delay-beregning
Delay skal beregnes med flere metoder:
impulsbasert ankomst, bandbegrenset impuls, fasehelling, group delay, cross-correlation og sum-/null-optimalisering.
Delay i frekvensdomenet implementeres som:
H_delayed(f) = H(f) * exp(-j * 2π * f * delay_seconds)
Søket skal først være grovt og deretter fint. Typisk:
sub/mid: bredt søk, for eksempel ±20 ms
mid/horn/diskant: smalere søk, for eksempel ±5 ms
grov oppløsning: 0.05–0.1 ms
fin oppløsning: 0.005–0.02 ms
Ingen enkeltmetode er fasit. Motoren skal beregne delay_confidence fra samsvar mellom impuls, fase, group delay, normal sum og invertert null.
Praktisk DSP-delay kan ikke være negativ. Etter relativ delayoptimalisering skal alle kanaler normaliseres slik at tidligste akustiske kanal får 0 ms praktisk delay, og andre kanaler får positiv delay. Den relative origo-modellen skal likevel beholdes.
- Fasekrav i deleområdet
Relativ fase beregnes som:
phase_diff(f) = unwrap(angle(H_A(f))) - unwrap(angle(H_B(f)))
Fase skal vurderes over et bånd rundt delefrekvensen, ikke bare i ett punkt.
Veiledende akseptgrenser:
ideelt: nær 0° relativ fasefeil ved Linkwitz-Riley akustisk mål
meget godt: innen ±15° rundt delefrekvens
akseptabelt: innen ±30° dersom normal sum, invertert null og robusthet er gode
betinget: ±30–45° bare dersom sum og null fortsatt er gode
ikke godkjent: over ±45° dersom dette gir dip, lobing, dårlig null eller ustabil sum
Motoren skal beregne:
phase_error_at_fx, mean_phase_error_around_fx, max_phase_error_around_fx, phase_slope_error, group_delay_difference og phase_robustness_score.
Fase kan aldri godkjennes alene. Den må stemme med normal sum og invertert null.
- Invertert null
Invertert null brukes som verifikasjon, ikke som eneste mål.
Motoren skal beregne:
null_depth_at_fx, mean_null_depth_around_fx, null_width_octaves, null_center_frequency, null_symmetry og null_robustness.
En god null skal være dyp nok, bred nok, sentrert nok og samsvare med god normal sum. En smal tilfeldig null skal ikke overbelønnes.
- Gain-styring
Driver-gain justeres før EQ. Gain er grov energibalanse, ikke et verktøy for å skjule lokale feil.
For driver D:
level_D = weighted_mean_db(|H_D(f)|, valid_band_D)
gain_needed_db = target_level_db - level_D
Gain skal beregnes over gyldig arbeidsområde, ikke fra én frekvens. Vekt lavere nær delefilterflanker, romdipper, lav SNR og utenfor trygt arbeidsområde.
Etter gainendring skal motoren alltid re-sjekke:
normal sum, invertert null, fase, headroom, driverstress, L/R-balanse og origo-tid.
Hvis gainendringen er stor, skal delay re-sjekkes lokalt rundt eksisterende verdi.
- EQ-strategi
EQ skal bare brukes etter at gain, delefilter, delay, polaritet og origo er stabile.
Målet er kontrollert respons etter target-kurve, ikke matematisk flathet. Target kan være brukerdefinert eller Harman-inspirert med romtilpasset bass og lett fallende energi mot toppen.
EQ-feil beregnes som:
error_db(f) = target_db(f) - measured_db(f)
Før EQ skal avvik klassifiseres som:
bred tonal ubalanse, minimum-phase peak, minimum-phase resonans, rommode, romnull, refleksjonskamfilter, driveroppbrytning, direktivitetsproblem, målefeil, L/R-asymmetri eller XO/fasefeil.
Kun egnede avvik skal EQ-korrigeres. Dype romnuller, ikke-minimum-phase dipper, kamfilter og direktivitetsfall skal ikke boostes.
- EQ-filtertyper og filtermodell
EQ-modulen skal støtte Pro-Q-lignende parametriske metoder:
bell, low shelf, high shelf, tilt shelf, notch, bandpass, highpass, lowpass, allpass, per-driver EQ, per-side EQ, global voicing EQ og senere eventuell dynamisk EQ.
Hvert filterobjekt skal inneholde:
filter_id, filter_type, frequency_hz, gain_db, Q, slope hvis relevant, channel_scope, driver_scope, phase_mode, enabled, reason, confidence, pre_score, post_score, headroom_cost, phase_cost, group_delay_cost, distortion_cost, power_response_cost, room_likelihood og minimum_phase_likelihood.
Total EQ:
H_EQ_total(f) = Π H_EQ_i(f)
Simulert respons etter EQ:
H_after(f) = H_before(f) * H_EQ_total(f)
- Q-håndtering
Q skal velges etter årsak, ikke for å pynte kurven.
Veiledende:
bred tonal justering: Q 0.3–1.0
vanlig bred PEQ: Q 0.7–2.0
lokal peak/resonans: Q 2–6
smal notch: Q 6–12 bare ved stabil resonans
Q over 12 krever høy confidence og validering
høy-Q boost skal normalt forbys
smal boost i dip skal forbys uten minimum-phase-bevis og flerposisjonsstabilitet
Q kan beregnes fra båndbredde:
Q = f_center / bandwidth_hz
Hvert filter skal vurderes for ringing, group delay impact, time-domain smearing og phase rotation.
- Minimum-phase-test
Før presis EQ eller boost skal motoren vurdere om avviket er minimum-phase.
Sammenlign:
målt fase, minimum-phase-estimat fra magnitude og excess phase.
Hvis avviket ikke er minimum-phase, skal EQ begrenses til kutt eller bred voicing, ikke full korreksjon.
- Powerrespons og direktivitet
Motoren skal ikke optimalisere on-axis alene dersom det gir feil total energirespons.
Hvis off-axis-data finnes, beregn:
on-axis response, off-axis response, listening window, early reflection estimate, sound power estimate og directivity index.
Hvis full polar-data ikke finnes, bruk proxyer:
driverdiameter, hornspredning, delefrekvens, bølgelengde, driveravstand, on/off-axis-data hvis tilgjengelig og romrespons.
Bølgelengde:
wavelength_m = speed_of_sound_m_s / frequency_hz
Driveravstand relativt til bølgelengde:
spacing_ratio = acoustic_center_distance_m / wavelength_m
Høy spacing_ratio i deleområdet skal øke lobing_risk_score.
DSP skal ikke kreve mer akustisk energi fra en driver enn driveren naturlig kan levere kontrollert. Ikke boost for å kompensere for direktivitetstap, powerrespons, oppbrytning, romnull eller naturlig avrulling utenfor trygt arbeidsområde.
- Forvrengning
Hvis REW-data inneholder harmonisk forvrengning, skal motoren bruke:
THD(f), H2(f), H3(f), H4(f), H5(f), IMD hvis tilgjengelig, noise floor og distortion_vs_SPL hvis flere nivåmålinger finnes.
H3 og høyere skal normalt straffes mer enn H2. Økende forvrengning nær delefrekvens kan flytte delepunktet.
Regler:
Hvis forvrengning stiger under en frekvens, skal driveren ikke deles for lavt.
Hvis diskant/horn viser økende H3/H5 nær nedre område, flytt delepunkt opp eller bruk brattere slope.
Hvis bass/mellombass viser økt forvrengning i øvre område, flytt delepunkt ned eller bratt filter.
EQ-boost som øker forventet forvrengning i risikobånd skal forkastes.
Kutt som reduserer energi i forvrengningsområde uten å skade sum/fase kan belønnes.
Motoren skal rapportere:
distortion_safe_band, distortion_warning_band og distortion_reject_band.
- Headroom og driverstress
For hver kanal skal motoren beregne:
digital_peak_margin_db, RMS_margin_db, cumulative_boost_db(f), max_boost_db, expected_excursion_risk, thermal_risk, low_frequency_risk, horn_low_cutoff_risk, tweeter_low_cutoff_risk og breakup_region_risk.
Boost under tuning, i romnuller, nær diskantens nedre grense eller under hornets trygge område skal forbys som standard eller gis svært høy straff.
- Romanalyse
Under ca. 200–300 Hz skal motoren anta at rommet dominerer mer. Bruk flere måleposisjoner, L/R separat og L+R. Finn rommoder, brede topper og posisjonsavhengige nuller. Kutt brede/modale topper forsiktig. Ikke boost smale nuller. Foreslå plassering, subintegrasjon eller delay før EQ.
Over ca. 300 Hz skal gated/direct sound brukes til driverrespons, mens rominkludert måling brukes til tonal balanse. Ikke korriger smale kamfilterdipper aggressivt. Bruk bred EQ bare ved stabile avvik.
For hvert avvik skal motoren beregne room_likelihood_score. Høy room_likelihood_score skal redusere EQ-aggressivitet.
- Venstre/høyre og stereosenter
Motoren skal beregne:
L_mag(f), R_mag(f), LR_error_db(f), L_phase(f), R_phase(f), LR_phase_diff(f), L_arrival_time, R_arrival_time, LR_delay_offset_ms, cross_correlation_offset_ms, center_band_level_difference_db, center_band_phase_difference og stereo_symmetry_score.
Sentrert lydbilde skal vurderes fra:
L/R delay match, L/R gain match, L/R phase match i stemmeområdet, L/R tonal match, mono sum stability, fravær av sterke asymmetriske refleksjoner og origo consistency.
Senter skal korrigeres i denne rekkefølgen:
routing/polaritet, L/R delay, L/R bred gain, bred tonal EQ, romtiltak/plassering.
Smal EQ skal ikke brukes som første løsning for å fikse senter.
- Origojustering
Systemet skal ha eksplisitt origo-modell:
SystemOrigin {
x
y
z
t_ms
reference_measurement_id
confidence
}
DriverNode {
side
driver_id
x
y
z
acoustic_t_ms
DSP_delay_ms
gain_db
polarity
valid_band
confidence
}
Alle delayverdier skal rapporteres som:
relativ akustisk tid mot origo
praktisk DSP-delay
fysisk ekvivalent avstand
distance_cm = delay_ms * 34.3
Origojustering er godkjent bare dersom:
driveroverganger summerer riktig, invertert null er god, L/R ankomst er symmetrisk, senterbildet er stabilt, subintegrasjon ikke trekker tidsreferansen feil, ingen kanal krever ufysisk delay og valideringsmåling stemmer med simulering.
- Robusthet
Hver kandidat skal testes med perturbasjoner:
delay ±0.05 ms, ±0.10 ms og ±0.20 ms
gain ±0.25 dB og ±0.50 dB
delefrekvens ±5 % og ±10 %
mikrofonposisjon hvis flere målinger finnes
En kandidat skal bare score høyt dersom den ikke kollapser ved små realistiske avvik.
- Scoremodell
Hver kandidat skal ha delscore:
measurement_quality_score, normal_sum_score, invert_null_score, phase_alignment_score, group_delay_score, magnitude_target_score, robustness_score, driver_stress_score, distortion_score, headroom_score, power_response_score, room_handling_score, LR_symmetry_score, center_image_score, origo_consistency_score og physical_plausibility_score.
Total score kan brukes til rangering, men må aldri skjule kritiske feil. Hvis én kritisk delscore feiler, skal kandidaten forkastes selv om total score er høy.
Kritiske fail-kriterier:
lav målekvalitet, ukjent routing, ukjent polaritet, dårlig normal sum rundt delepunkt, manglende invertert null der den forventes, stor L/R-delayfeil, stor headroom-reduksjon, boost i romnull, boost under trygg drivergrense, tydelig powerrespons-degradering, økt forvrengningsrisiko, origo-inkonsistens eller simulering som ikke stemmer med valideringsmåling.
- Non-degradation gate
Etter hver endring i XO, delay, gain, polaritet, EQ eller target skal motoren sammenligne mot forrige godkjente baseline.
Endringen godkjennes bare hvis:
target error forbedres, normal sum ikke degraderes, invertert null ikke degraderes vesentlig, fase ikke degraderes, group delay ikke får nye store avvik, headroom holder seg innen krav, driverstress ikke øker uakseptabelt, forvrengningsrisiko ikke øker uakseptabelt, powerrespons ikke blir åpenbart dårligere, L/R-symmetri ikke forverres, senter ikke flytter seg, origo fortsatt er konsistent og simulert effekt er realistisk.
Hvis testen feiler, skal motoren rollback’e og logge årsak.
- Validering med REW
Etter valgt kandidat skal motoren produsere testplan:
mål hver driver med ny gain/EQ/filter alene
mål parvise summer normal
mål parvise summer invertert
mål venstre fullrange
mål høyre fullrange
mål L+R mono for bass og senterkontroll
mål flere posisjoner i bassområdet
sammenlign målt respons mot simulert respons
Avvik beregnes som:
simulation_error_db(f) = measured_after_db(f) - predicted_after_db(f)
Hvis simulering og måling ikke stemmer, sjekk først:
filterimplementasjon, delay-fortegn, gain, routing, polaritet, REW timing reference, sample rate, latency, kanalbytte, plugin latency og målevindu/gate.
- Når systemet kan kalles optimalisert
Motoren kan bare rapportere “optimalisert” når:
målinger er gyldige, routing er verifisert, polaritet er verifisert, alle driveroverganger har god normal sum, relevante overganger har god invertert null, fase er innen akseptabelt område, delay er konsistent mellom impuls/fase/sum/origo, gain er balansert uten ekstrem kompensasjon, EQ er konservativ og årsaksbasert, Q passer problemet, powerrespons ikke er åpenbart degradert, forvrengning og driverstress er innenfor krav, headroom er bevart, romrelaterte avvik er korrekt klassifisert, L/R er tilstrekkelig symmetrisk, senterbildet er stabilt, sluttmåling stemmer med simulering og ingen non-degradation gate feiler.
Hvis dette ikke kan bevises, skal motoren rapportere “ikke optimalisert ennå” og forklare hva som mangler.
- Sluttrapport
Motoren skal alltid skrive:
hva som ble målt, hvilke data som ble brukt, hvilke data som ble forkastet, målekvalitet, valgt origo, delay per driver relativt til origo, praktisk DSP-delay per kanal, fysisk avstandsekvivalent, gain per driver, XO per overgang, slope per overgang, polaritet, EQ per driver/side, Q-begrunnelse, hvilke avvik som ikke ble korrigert og hvorfor, romrelaterte funn, powerresponsvurdering, forvrengningsvurdering, L/R-symmetri før/etter, center_image_score før/etter, headroom før/etter, driverstress før/etter, simulert vs målt avvik, pass/fail for regresjonstester, beste alternative kandidater og hva som eventuelt må måles på nytt.
- Hovedregel
ML motoren skal ikke optimalisere én graf. Det skal optimalisere et fysisk høyttalersystem i et faktisk rom. Alle valg skal være små, målbare, reversible og begrunnet i kompleks respons, fase, tid, gain, powerrespons, forvrengning, romklassifisering, robusthet, headroom, driverstress, L/R-symmetri og origojustering. -
Laster inn…
Diskusjonstråd Se tråd i gallerivisning
-
Laster inn…