Behövs mer än 16bit/44kHz?

[RogerJoensson]

Nu ligger min SRC med på sidan:
http://src.infinitewave.ca/

Titta under "tolvan"

*lite stolt*

Tummen upp!

-Inte helt olik OS X Afconvert (Bats), som ju anses vara bra! (finns också på nämnda sida).

Afconvert (Bats) verkar använda samma filter som Core Audio, bara det att för att kunna spela upp i realtid med högsta kvalitén så man måste ha ett program som ställer kvalitén högre än iTunes standardläge, om jag fattat rätt. Det lät naturligtvis vara mycket mer processorbelastande än standardfiltret.

[Svante]

-Inte helt olik OS X Afconvert (Bats), som ju anses vara bra! (finns också på nämnda sida).

Nä, den var väldigt lik faktiskt. Enda skillnaden jag kan se är att min har lite mindre dist . Sen får man ju inte veta något om hur fort det går, min går långsammare än realtid på min dator.

[IngOehman]

Kul med riktiga mätningar!

Bandpassfilterlösningen är ekvivalent med en ökad komplexitet i rekonstruktionsfiltret, dock är det ovanligt med hybridlösningar av IIR- och FIR-filter. Faslinjäriteten går förlorad om man blandar (om det är viktigt kan diskuteras).

Faslinjäriteten får förlorad om man blandar skriver du... Men det behöver den ju inte göra. FIR-delen kan förvisso göras faslinjär, men den behöver ju inte vara faslinjär, som enskildhet. Den kan dimensioneras således att summan blir faslinjär. I varje fall upp till 21 kHz eller vad man nu kan tänkas vilja tycka är bra.

Jag hoppas att vi framöver kommer att få se lösningar som är rätt från början i stället, men klart är nog att de där omsamplarna skulle detekteras i blindtest.

Ja, långt ifrån att är perfekt sound forever, per automatik, bara för att det är digitalt.


Vh,iö

[Svante]

Kul med riktiga mätningar!

Bandpassfilterlösningen är ekvivalent med en ökad komplexitet i rekonstruktionsfiltret, dock är det ovanligt med hybridlösningar av IIR- och FIR-filter. Faslinjäriteten går förlorad om man blandar (om det är viktigt kan diskuteras).

Faslinjäriteten får förlorad om man blandar skriver du... Men det behöver den ju inte göra. FIR-delen kan förvisso göras faslinjär, men den behöver ju inte vara faslinjär, som enskildhet. Den kan dimensioneras således att summan blir faslinjär. I varje fall upp till 21 kHz eller vad man nu kan tänkas vilja tycka är bra.

Alltså, i det här sammanhanget är det nog så, här tänkte man sig att kompensera ett FIR-filters bristande tonkurva med ett IIR-filter.

[Almen]

Nu ligger min SRC med på sidan:
http://src.infinitewave.ca/

Titta under "tolvan"

*lite stolt*

Vajert, Svante!

[RogerJoensson]

-Inte helt olik OS X Afconvert (Bats), som ju anses vara bra! (finns också på nämnda sida).

Nä, den var väldigt lik faktiskt. Enda skillnaden jag kan se är att min har lite mindre dist . Sen får man ju inte veta något om hur fort det går, min går långsammare än realtid på min dator.

Jag testade med OSX-terminalen och körde uppsampling med afconvert "bats" på 24bitars 44.1KHz stereo filer till 96KHz flyttal.
Med 100% processor (av totalt 400%) gick det i 12 gånger realtid (i7 2.7GHz), om även grafikchipet och annat används har jag ingen aning om. Det borde alltså gå att göra nästan fyra samtidiga uppsamplingar utan att tappa hastighet.
Nersampling 96-44.1 görs ca 9 gånger realtid.
Med tanke på att du säger att din konvertering inte ens går i realtid, så bli jag misstänksam om jag gjort något fel.

Terminalscript för uppsampling: - afconvert infil.aif -d LEF32@96000 -f WAVE --src-complexity bats -r 127 utfil.wav - (det går att blanda format).

Nivåskillnaderna var mindre än min mätare visade och låg spikat på samma värde upp till 21KHz (dB, en decimal) och förmodligen lite däröver. Speglingsskräpet/disten höll sig på ungefär -100dB (runt 18KHz steg det något till -98dB, och över 19KHz minskade det till ungefär-105dB)
Jag testade med fasta sinusar i tätare (500Hz) intervall mellan 17-21KHz. En sista koll gjordes vid 21.8KHz och där hade nivån fallit 2.9dB.

Igen. Jag är osäker på om jag gjort något fel. Scriptet finns ovan, om någon annan vill testa.
Jag ska testa och mäta nersampling senare. Dags att ta itu med jobbet igen.

[Svante]

Med tanke på att du säger att din konvertering inte ens går i realtid, så bli jag misstänksam om jag gjort något fel.

Säkert inte, det beror nog på att jag inte parallellprocessar, möjligen också på att mitt prog är 32-bit (men räknar med 64-bit float). Jag skulle gissa att det andra programmet lägger ut omsamplingen på flera kärnor och räknar med 32-bit floats (därav den högre disten), samt att det är ett 64-bitsprogram, vilket nog gör det snabbare. Möjligen finns det också knep att ta till om man begränsar sig till vanliga konverteringsfrekvenser, min är hyfsat generell och går lika snabbt för alla heltalsförhållanden n/m där n och m<2000. Min kan även ta godtyckliga frekvensförhållanden, men då blir det sirap i systemet (ytterligare en faktor 10 långsammare) Man kan nog ta hjälp av FFT också, och det gör inte jag.

[RogerJoensson]

Med tanke på att du säger att din konvertering inte ens går i realtid, så bli jag misstänksam om jag gjort något fel.

Säkert inte, det beror nog på att jag inte parallellprocessar, möjligen också på att mitt prog är 32-bit (men räknar med 64-bit float). Jag skulle gissa att det andra programmet lägger ut omsamplingen på flera kärnor

Det verkar inte så. Processorbelastningen ligger vid omsampling på 99% av max 400%. Om jag komprimerar video ligger processorbelastningen nära 400% (alla kärnorna jobbar). Hm. Nu läser jag i att det bara sitter dubbla kärnor i processorn (varför då upp till 400%)? Hm Hm Hm...
Nåväl 100% av 400%. -Det var därför jag skrev att det borde gå att uppsampla fyra filer parallellt utan att tappa bearbetningshastighet (per fil).
Halva tiden har jag för mig att det rapporterades att fyra trådar var igång, därefter två (vad nu det innebär).

[AndreasArvidsson]

Hm. Nu läser jag i att det bara sitter dubbla kärnor i processorn (varför då upp till 400%)? Hm Hm Hm...

Hyperthreading gissar jag på. Då har du 2st logiska kärnor för var fysisk.

[RogerJoensson]

Jo, jag sökte just och läste om det (du svarade medan jag läste...). Den som skrev kallade det virtuella kärnor.
Frågan är varför processorbelastningen stannar vid just 99%? Kanske är det för att datorn ska vara normalt användbar under tiden. Kanske finns inställningar för detta (för afconvert), som jag inte sökt efter och därför inte hittat.
Jag drog in en stor fil för att se om kylfläkten drar igång ala videokomprimerande. Det gör den inte. Inte lika snabbt i alla fall.

[Svante]

Med tanke på att du säger att din konvertering inte ens går i realtid, så bli jag misstänksam om jag gjort något fel.

Säkert inte, det beror nog på att jag inte parallellprocessar, möjligen också på att mitt prog är 32-bit (men räknar med 64-bit float). Jag skulle gissa att det andra programmet lägger ut omsamplingen på flera kärnor

Det verkar inte så. Processorbelastningen ligger vid omsampling på 99% av max 400%. Om jag komprimerar video ligger processorbelastningen nära 400% (alla kärnorna jobbar). Hm. Nu läser jag i att det bara sitter dubbla kärnor i processorn (varför då upp till 400%)? Hm Hm Hm...
Nåväl 100% av 400%. -Det var därför jag skrev att det borde gå att uppsampla fyra filer parallellt utan att tappa bearbetningshastighet (per fil).
Halva tiden har jag för mig att det rapporterades att fyra trådar var igång, därefter två (vad nu det innebär).

Ja, ok, hursomhelst har jag inte hårdoptimerat för hastighet. Jag har dock städat bort ganska många småbuggar som gjorde kvaliteten sämre än bäst. Det är ganska lätt att göra olika obra saker.

[Johan_Lindroos]

Nu ligger min SRC med på sidan:
http://src.infinitewave.ca/

Titta under "tolvan"

*lite stolt*

Ja, din SRC verkar ju väldigt trevlig!

Jag stöter dock på ett litet problem när jag försöker prova den i Sopran. Som jag förstår det ska man lägga den som en process som man sedan exekverar genom att köra "Run". Men när jag kör så säger den att det för en normallång låt tar 0,001 sekunder vilket verkar misstänkt kort tid då jag använder av vanlig lapptopp. Jag försökte köra "Insane" och omsampling till fs = 48 kHz, och vid efterkontroll låg låten kvar i ursprunglig samplingsfrekvens (44,1 kHz). Har du något tips hur man ska göra?

Jag hittar inte heller någon funktion för att höja och sänka nivå.

[Svante]

Jag stöter dock på ett litet problem när jag försöker prova den i Sopran. Som jag förstår det ska man lägga den som en process som man sedan exekverar genom att köra "Run". Men när jag kör så säger den att det för en normallång låt tar 0,001 sekunder vilket verkar misstänkt kort tid då jag använder av vanlig lapptopp. Jag försökte köra "Insane" och omsampling till fs = 48 kHz, och vid efterkontroll låg låten kvar i ursprunglig samplingsfrekvens (44,1 kHz). Har du något tips hur man ska göra?

Jag hittar inte heller någon funktion för att höja och sänka nivå.

Detta kan vara en ledtråd. Du kan även ändra nivån i delar med edit levels om du svärtar det du vill ändra nivån på först. (Sopran har enn lite annat "tänk" än program som ProTools i det att man faktiskt redigerar de sampel som man har i editorn. Protools har alltid kvar originalet, här får man fixa det själv. Det har både för- och nackdelar.)

[Johan_Lindroos]

Tack för tipsen!

Nu har jag fått det att fungera, och det fungerar mycket bra dessutom!

När man väl fått kläm på hur programmet fungerar, är det fantastiskt att kunna processa med matematik istället för tramsiga "reglage".

Funktionen för "enpulser" är även den mycket bra, det lyckades jag inte med i andra ljudredigeringsprogram.

Det är väldigt bra att man kan spara den lilla exekveringsfilen.

När jag sedan gjort små snuttar i Sopran, tyckte jag dock att det gick lättare att fortsätta att redigera i Adobe Audition.


Tips till alla: Prova Sopran! Det har även många andra trevliga funktioner såsom spektrogramanalys.

[lilltroll]

Svate: Använder du en polyphase implementation vid SRC ?

[Svante]

Svate: Använder du en polyphase implementation vid SRC ?

Ja, om fs1/fs2=n1/n2, där n1 och n2 är heltal <2000.