Bit lengde konvertering

O

Oblivion

Gjest
Er det noen som kjenner til eller kan lage et "bit lengde konverterings" program?

Det som er krav spesifikasjonen er:
1. Lese en 44.1k/16bit WAV fil og skrive den som en 44.1k/24bit fil.
2. De ekstra 8bit i hvert sample må skrives som "00000000" hvis MSB sign bit er "0",
og som "11111111" hvis MSB sign bit er "1".

Mulighet for å konvertere til 32bit er også ønskelig,
og også å konvertere 96k/24bit til 96k/32bit, og 192k/24bit til 192k/24bit på den samme måte.

EDIT: Rettet opp MSB sign bit verdiene..
 
O

Oblivion

Gjest
Sjekket SOX grovt nå, men det ser ikke ut til å løse mine "problemer"..
 
N

nb

Gjest
Oblivion skrev:
Sjekket SOX grovt nå, men det ser ikke ut til å løse mine "problemer"..
Jeg er ingen ekspert, men det kan i alle fall gjøre bitratekonvertering og sampleratekonvertering, det er jeg 99,9% sikker på. Hvordan det er med kravet ditt i forholt til MSB vet jeg dog ikke noe om.

Om du ikke finner noen bedre alternativer eller andre har bedre tips, så er det jo bare å fyre en mail til folkene bak Sox, muligens det kan løses på en eller annen måte.

Dette er en annen kandidat som gjør bitratekonvertering, men igjen vet jeg ikke om du kan styre noe vedr MSB

https://public.msli.com/lcs/audiomove/
 

KJ

Æresmedlem
Ble medlem
10.10.2004
Innlegg
11.093
Antall liker
4.197
Torget vurderinger
1
Kravspecen din er litt «ukurant». «Alle» (>99,9%?) formatkonvertere bruker dither når ordlengden økes, på de gode kan man også velge nivå og sannsynlighetsfordeling. Er det noen grunn til ikke å bruke dither?

mvh
KJ
 
O

Oblivion

Gjest
nb skrev:
Oblivion skrev:
Sjekket SOX grovt nå, men det ser ikke ut til å løse mine "problemer"..
Jeg er ingen ekspert, men det kan i alle fall gjøre bitratekonvertering og sampleratekonvertering, det er jeg 99,9% sikker på. Hvordan det er med kravet ditt i forholt til MSB vet jeg dog ikke noe om.

Om du ikke finner noen bedre alternativer eller andre har bedre tips, så er det jo bare å fyre en mail til folkene bak Sox, muligens det kan løses på en eller annen måte.

Dette er en annen kandidat som gjør bitratekonvertering, men igjen vet jeg ikke om du kan styre noe vedr MSB

https://public.msli.com/lcs/audiomove/
SOX og de fleste programmer jeg har sett på kan konvertere,
men jeg vil ha 100% kontroll slik at de blir konvertert slik som jeg beskrev.

SOX kan konvertere også uten dither fra 16bit til 24bit, men ikke med kontroll på HVA som er verdien i de ekstra 8bit.
Det er nettopp det at de ekstra 8bit i hvert sample må skrives som "00000000" hvis MSB sign bit er "0",
og som "11111111" hvis MSB sign bit er "1" som er mitt krav.

?bBITS,??bitsBITS
The number of bits (a.k.a. bit-depth or sometimes word-length) in each encoded sample. Not
applicable to complexencodings such as MP3 or GSM. Not necessary with encodings that have a
?xed number of bits, e.g. A/µ-law, ADPCM.
Foraninput ?le, the most common use for this option is to inform SoX of the number of bits per
sample in a ‘raw’ (‘headerless’) audio ?le. Forexample
sox -r 16k -e signed -b 8 input.raw output.wav
converts a particular ‘raw’ ?le to a self-describing ‘WAV’?le.
Foranoutput ?le, this option can be used (perhaps along with?e)toset the output encoding size.
By default (i.e. if this option is not given), the output encoding size will (providing it is supported
by the output ?le type) be set to the input encoding size. Forexample
sox input.cdda -b 24 output.wav
converts rawCDdigital audio (16-bit, signed-integer) to a 24-bit (signed-integer) ‘WAV’?le.
?1/?2/?3/?4/?8
The number of bytes in each encoded sample. Deprecated aliases for?b 8, ?b 16, ?b 24, ?b 32,
?b 64respectively.
 
O

Oblivion

Gjest
KJ skrev:
Kravspecen din er litt «ukurant». «Alle» (>99,9%?) formatkonvertere bruker dither når ordlengden økes, på de gode kan man også velge nivå og sannsynlighetsfordeling. Er det noen grunn til ikke å bruke dither?

mvh
KJ
Selvfølgelig er kravspecen "ukurant" og det er derfor jeg har startet denne tråden..
Hadde jeg hatt programmerings verktøy og erfaring med bruk av disse hadde jeg brukt en time eller to og skrevet konverterings programmet selv...
 

nma

Hi-Fi freak
Ble medlem
07.12.2003
Innlegg
4.696
Antall liker
518
Torget vurderinger
1
Det er ikke verre enn å åpne en fil i et lydredigeringsprogram og lagre den som 32bit.
 
O

Oblivion

Gjest
Man skrev:
Det er ikke verre enn å åpne en fil i et lydredigeringsprogram og lagre den som 32bit.
Og da kan en være sikker på at de ekstra 16bit i hvert sample er skrevet som "0000000000000000" hvis MSB sign bit er "0", og som "1111111111111111" hvis MSB sign bit er "1"....

Og også være sikker på at "lydredigeringsprogrammet" ikke har gjort andre morsomheter..

Det er nettopp fordi jeg har prøvd det du sier og erfart at det ikke blir gjort riktig at jeg prøver å finne et program som KUN gjør det jeg ønsker og NØYAKTIG det jeg ønsker.
 

trex

Overivrig entusiast
Ble medlem
05.07.2003
Innlegg
916
Antall liker
29
Ta kontakt med et mastering-studio, de har som regel stålkontroll på lydkonvertering i alle former.


f.eks. disse: http://www.lydmuren.no/index.php?page=Studio

eventuelt andre store studioer. De skal og må ha full kontroll og oversikt over enhver type AD/DA som blir gjort i tillegg til dithering.
 
O

Oblivion

Gjest
trex skrev:
Ta kontakt med et mastering-studio, de har som regel stålkontroll på lydkonvertering i alle former.
De skal og må ha full kontroll og oversikt over enhver type AD/DA som blir gjort i tillegg til dithering.
Jeg har fått konvertert endel wav filer med blant annet Sony software i et lite studio som har det siste innen high-tech hardware og software...
Det var etter dette jeg forstod at jeg måtte lete etter et program som IKKE er tiltenkt lydredigering eller SRC da det ser ut som om alle disse programmene desverre gjør langt mer enn det jeg ønsker å få gjort..
 

nma

Hi-Fi freak
Ble medlem
07.12.2003
Innlegg
4.696
Antall liker
518
Torget vurderinger
1
Kan jeg spørre om hva som er "teorien" bak dette uvanlige kravet?
 
O

Oblivion

Gjest
blekansikt skrev:
Finner du noe info her som kan hjelpe deg finne det du søker: http://duc.digidesign.com/showthread.php?t=232717

Mvh
Sture
Der fant jeg bare enda et bevis på hvor utbredt "feiltolkningen" av "Two's complement code" er eller at de diskuterer et annet unsigned integer code format..

Mange "tror" det er et rent 16bit data sample, men fordi det er "Two's complement code" som består av MSB sign bit som angir om det er et negativt eller positivt sample og 15bit med verdien hvor bitene i det negative samplet er den tilsvarende positive verdien invertert...
MSB sign bit har også en verdi = MSB.

Poenget er at de fleste programvarer og DACer legger til "0" for både negative og positive samples ved bit lengde økning - noe som er feil..

Negative samples må legges til med "1" fordi dette er en invertert verdi..

Det er derfor jeg vil øke bit lengden til 24bit eller 32bit på den korrekte måten..
All hardware og software etterpå vil da behandle samplene riktig.
Det er derfor mange 16bit NOS DACer ofte spiller så mye mer naturlig enn moderne høy-bit og oppsampling DACer.
NOS DACene skreller av de bit som er over 16 og er derfor ikke berørt av feilaktig bit lengde konvertering.

Legger ved sitat fra Wikipedia som kanskje beskriver dette mer forståelig:

Sign extension:
When turning a two's-complement number with a certain number of bits into one with more bits (e.g., when copying from a 1 byte variable to a two byte variable), the most-significant bit must be repeated in all the extra bits and lower bits.
 
O

Oblivion

Gjest
KJ skrev:
Oblivion skrev:
Hva er galt med dither?

mvh
KJ
Ingenting så lenge det er DACen som gjør det...
Fordi all DACer er forskjellige og filterne i DAC chipen lager den dither etc. som fungerer best..
Dither er jo støy og hvorfor ikke la DACen selv lage den støyen den optimalt trenger for fungere optimalt..
 

mesc

Hi-Fi entusiast
Ble medlem
27.08.2008
Innlegg
306
Antall liker
7
Sted
Rogaland
Regner med du har spurt i et mer dedikert programmeringsforum el. lignende?
www.diskusjon.no har jo eksempelvis et programmerings hjørne.
 

trex

Overivrig entusiast
Ble medlem
05.07.2003
Innlegg
916
Antall liker
29
Oblivion skrev:
trex skrev:
Ta kontakt med et mastering-studio, de har som regel stålkontroll på lydkonvertering i alle former.
De skal og må ha full kontroll og oversikt over enhver type AD/DA som blir gjort i tillegg til dithering.
Jeg har fått konvertert endel wav filer med blant annet Sony software i et lite studio som har det siste innen high-tech hardware og software...
Det var etter dette jeg forstod at jeg måtte lete etter et program som IKKE er tiltenkt lydredigering eller SRC da det ser ut som om alle disse programmene desverre gjør langt mer enn det jeg ønsker å få gjort..

Så langt jeg har undersøkt har IKKE studioene noen kontroll og vet ikke hva som skjer.
De har hardware og software som de har kjøpt og bruker dette i den tro at det gjør det riktige.
Det "riktige" i mitt tilfelle er IKKE normalen ved en konvertering.
Problemet er at min "problemstilling" tydligvis ikke kan kontrolleres i noe setup eller kommandolinje parametre....

Det må da være en grunn til at "normalen" er normalen, og at åpenbart ingen bruker det du er ute etter.....eller??

Ser at du ønsker å legge dithering i DAC'en, problemet er vel her at all "ferdig" musikk er allerede tillagt dither, og man bør vel helst
gjøre dette kun 1 gang totalt, uten at jeg er noen ekspert på dette.

Det fine er at alt kan programmeres, så du må nok søke, som nevnt over, i utvikler-miljøene.
 
O

Oblivion

Gjest
trex skrev:
Det må da være en grunn til at "normalen" er normalen, og at åpenbart ingen bruker det du er ute etter.....eller??

Ser at du ønsker å legge dithering i DAC'en, problemet er vel her at all "ferdig" musikk er allerede tillagt dither, og man bør vel helst
gjøre dette kun 1 gang totalt, uten at jeg er noen ekspert på dette.

Det fine er at alt kan programmeres, så du må nok søke, som nevnt over, i utvikler-miljøene.
Problemet er at det ser ut til at både software og DAC hardware ikke alltid øker bitlengden riktig..
Om dette er gjort pga uvitenhet eller fordi det krever mer prossesering eller mer avansert hardware og vurdert til å ikke være hørbart og derfor ikke "nødvendig" vet jeg ikke..
Men når jeg nå kan høre forskjell ønsker jeg å gjøre dette kontrollert og korrekt.

Når det gjelder dither er det ille nok at dette er gjort allerede ved mastering fordi moderne DACer / digital filtre gjør dette en gang til - derfor vil jeg unngå å få et tredje dither nivå ved konvertering fra 16bit til 24 eller 32bit.
 
O

Oblivion

Gjest
Problemet blir nå løst og jeg trenger ikke lenger en SW konverter..

Det viste seg at SD kort spilleren også konverterte 16bit til 32bit og at dette ble gjort feil - padding med "0" for både positive og negative samples....
Nå blir SD kort spilleren oppgradert slik at den konverterer korrekt fra 16 og 24bit og opp til 32bit.
 

trex

Overivrig entusiast
Ble medlem
05.07.2003
Innlegg
916
Antall liker
29
Interessant, så hvis man f.eks. i en opptakssekvens holder seg på 24bit hele veien og ikke bruker dither (som er den vanlige måten å gjøre det på), så skjer det ikke noe galt. Det er først når det blir konvertert til 16bit (eller 32bit for den saks skyld) at problemet oppstår?
Hvis jeg forstår det korrekt.


Dither blir tilført i masteringprosessen enten man liker det eller ikke, tror det er vanskelig å få gjort noe med det.

Bra at du har funnet en løsning!
 

Skink_123

Bransjeaktør
Ble medlem
08.10.2008
Innlegg
4.637
Antall liker
1.346
Sted
Oslo
Torget vurderinger
4
Så hva er den perfekte kombinasjon om en tenker på korrekt bitlengde og totalt uavhengig av strømnettet kombinasjon?
 

KJ

Æresmedlem
Ble medlem
10.10.2004
Innlegg
11.093
Antall liker
4.197
Torget vurderinger
1
o.t.?
Oblivion skrev:
...
Når det gjelder dither er det ille nok at dette er gjort allerede ved mastering fordi moderne DACer / digital filtre gjør dette en gang til - derfor vil jeg unngå å få et tredje dither nivå ved konvertering fra 16bit til 24 eller 32bit.
t.o. å «kappe» bits for å komme ned fra 24 eller 32 til 16 uten dither låter værre enn de aller fleste former for dither. Korekt utført dither for å komme ned til 16 bit, vil også bidra til å opprettholde noe av dynamikkområdet under -96 dB FS (dvs i den grad orginalen har noe «matnyttig» informasjon så langt ned), informasjon ned mot omkring -110 til -120 dB FS kan kodes inn på 16 bit med dither.

mvh
KJ
 

nma

Hi-Fi freak
Ble medlem
07.12.2003
Innlegg
4.696
Antall liker
518
Torget vurderinger
1
Oblivion skrev:
blekansikt skrev:
Finner du noe info her som kan hjelpe deg finne det du søker: http://duc.digidesign.com/showthread.php?t=232717

Mvh
Sture
Der fant jeg bare enda et bevis på hvor utbredt "feiltolkningen" av "Two's complement code" er eller at de diskuterer et annet unsigned integer code format..

Alle "tror" det er et rent 16bit data sample, men fordi det er "Two's complement code" som består av MSB sign bit som angir om det er et negativt eller positivt sample og 15bit med verdien hvor bitene i det negative samplet er den tilsvarende positive verdien invertert...

Poenget er at de fleste programvarer og DACer legger til "0" for både negative og positive samples ved bit lengde økning - noe som er feil..

Negative samples må legges til med "1" fordi dette er en invertert verdi..

Det er derfor jeg vil øke bit lengden til 24bit eller 32bit på den korrekte måten..
All hardware og software etterpå vil da behandle samplene riktig.
Der hvor hardware eller software gjør dette feil fra en 16bit fil får en 48dB (24bit) eller 96dB (32bit) høyere "crossover forvrengning" (i forhold til LSB) i forhold til en korrekt konvertering pluss at alle negative samples får feil verdi og vil gi høy hørbar forvrengning - det er derfor mange 16bit NOS DACer ofte spiller så mye mer naturlig enn moderne høy-bit og oppsampling DACer når disse fores med 16bit data...
"Ekte" 24bit eller 32bit code til disse DACene spiller ofte mye naturligere og uten den kalde grå "fargingen" av lyden..

Legger ved sitat fra Wikipedia som kanskje beskriver dette mer forståelig:

Sign extension:
When turning a two's-complement number with a certain number of bits into one with more bits (e.g., when copying from a 1 byte variable to a two byte variable), the most-significant bit must be repeated in all the extra bits and lower bits.
Nå er det litt vanskelig å følge deg. I det første innlegget vil du invertere ekstra bits jmf MSB. Men nå vil du repetere MSB i ekstra bits..?

Det er uansett ikke feil, i motsetning til hva du påstår, å legge utelukkende til 0'er til ekstra bits ved konvertering fra 16bits til 24 eller 32. Noe annet vil medføre at man legger til kunstig presisjon ved negative samples men ikke ved positive samples. Hvor er logikken i dette?
Dessuten har du faktisk misforstått wiki-artikkelen du siterer. MSB repeteres kun på venstre side, mens ved venstreshift (som da er gjeldende for audio) legges 0 til ekstra bits på høyre side. Legger man til kunstig informasjon får man regnefeil, enten det gjelder vanlig programmering, eller audio.
 
O

Oblivion

Gjest
Man skrev:
Nå er det litt vanskelig å følge deg. I det første innlegget vil du invertere ekstra bits jmf MSB. Men nå vil du repetere MSB i ekstra bits..?

Det er uansett ikke feil, i motsetning til hva du påstår, å legge utelukkende til 0'er til ekstra bits ved konvertering fra 16bits til 24 eller 32. Noe annet vil medføre at man legger til kunstig presisjon ved negative samples men ikke ved positive samples. Hvor er logikken i dette?
Dessuten har du faktisk misforstått wiki-artikkelen du siterer. MSB repeteres kun på venstre side, mens ved venstreshift (som da er gjeldende for audio) legges 0 til ekstra bits på høyre side. Legger man til kunstig informasjon får man regnefeil, enten det gjelder vanlig programmering, eller audio.
Beklager at jeg skrev feil i startinnleggene!
Det er "1" som skal brukes når MSB er "1" og "0" som skal brukes når MSB er "0".

Hvis du tenker deg om og sjekker en gang til og ikke tenker rene binære verdier eller "one´s compliment code",
men "two´s compliment code" vil du forstå det.
I "two´s compliment code" brukes også MSB sign bit som data og er MSB bit.
"two´s compliment code" er kodet på denne måten fordi selve digital til analog konverteringen kan gjøre ved å bruke et serielt til paralellt shift register uten noen som helst fixfaxeri.
Hvis MSB blir representert med for eksempel en 100ohms motstand blir neste bit 200ohm så 400ohm etc..
"two´s compliment code" gir en LSB feil verdi og dette blir normalt kompensert, men på forskjellige måter.

Det viser seg at "problemet" med feil verdier i de negative samples ved "bit lengde økning ser" ut til å skyldes flere årsaker:
1. Fordi det i dag brukes FS*64 word/LR klokke blir et 16bit sample klokket med 32 * bit klokke signalet.
De 16 LSB bitene blir klokket som "0" fordi det ikke er data.
Dette skjer for både negative og positive samples.
2. Feilen skjer når og hvis mottager bruker mer enn den opprinnelige bit lengden i samplet.
Altså bruker bit fyllet som ikke har signifikans og som ikke har vært tiltenkt brukt som data.
3. Utfordringen blir at en må ha en prosessor som setter opp for eksempel en DAC for å motta og bruke kun 16bit hvis det er 16bit data, kun 20bit hvis det er 20bit data, kun 24bit hvis det er 24bit data og 32bit kun når det er 32bit data.
4. Med SPDIF kan dette enkelt løses ved å lese status registerne i SPDIF mottageren,
men med I2S hvor det ikke sendes med status informasjon blir dette vanskeligere å få til..
5. Et flertall av DACer, og Multi spillere med integrert DAC er konstruert så enkelt at de ikke sjekker bit lengden på data, men klokker inn og bruker 24bit eller 32bit i tilfelle av en ESS DAC...
Og feil data blir da brukt når det er mindre enn 24 eller 32bit i musikk data bit lengden.
6. Hvis ikke programvare sjekker bit lengden og skreller av de bit som ikke er data, men bruker "bit fyllet" som data blir det tilsvarende feil i all konvertering softwaren gjør.
Og det hjelper da ikke om alt som skjer "inne" i softwaren er korrekt..
7. Dette "problemet" er størst med de DAC chiper som tar i mot størst bit lengde slik som ESS sine 32bit DACer.
Fordi jeg bruker ESS DAC og SD kort avspiller via I2S fikk jeg oppleve den størst mulige konsekvens av denne typen feil når SD kort spilleren hadde 44.1k/16bit data.
Dette var godt hørbart og når jeg gikk ned til 24bit ble det mindre generende, men fortsatt hørbart.

PS! I min implementasjon av DAC blir nå SPDIF status sjekket og DACen blir satt opp til å bruke 16/20/24bit data lengde som matcher den sendte data lengden.
For I2S inngangene blir det i første omgang en manuell konfigurering pr. inngang hvor jeg må velge mellom 16/20/24 eller 32bit data lengde.
SD kort spilleren er en I2C master og den blir etterhvert oppdatert slik at den setter opp DAC til den data bit lengden som avspilles eller en kan bruke SPDIF utgangen inntil oppdateringen er utført.
DSD inngang blir uendret da jeg ikke har funnet noen utfordringer så langt..
 

KJ

Æresmedlem
Ble medlem
10.10.2004
Innlegg
11.093
Antall liker
4.197
Torget vurderinger
1
Oblivion skrev:
Jeg tror jeg holder med Man her ...

La oss ta det aller enkleste 2-bits og desimalverdiene +1, null og -1 , dvs binære verdier på 01, 00 og 11 med two's-complement. Med metoden din for å øke til 3 bits så blir det 010=2, 000=0 og 111=-1, 4 bits gir 0100=4, 0000=0 og 1111=-1. Dersom vi bare fyller på med null så får vi 010=2, 000=0 og 110=-2 med 3 bits, og 0100=4, 0000=0 og 1100=-4 med 4bits. Med din metode for å «fylle på» nye bits, så får du en asymetrisk skalering av de bineære tallene slik at -1 holdes uforandret uavhengig av antall nye bits, mens +1 skaleres iht antall nye bits => med andre ord økt 2. harmonisk forvregning. Dersom det bare fylles på med null så er skaleringen på begge sidene av null-punktet lik og forvregningsstrukturen påvirkes i utgangspunktet ikke.

Det blir som du foreskriver dersom det skal fylles på med bits på MSB-siden av bitstrengen, men ikke på LSB-siden av strengen.

jf. http://en.wikipedia.org/wiki/Two's_complement

mvh
KJ
(med forbehold om at jeg intet har forstått)
 

nma

Hi-Fi freak
Ble medlem
07.12.2003
Innlegg
4.696
Antall liker
518
Torget vurderinger
1
Om du hører forskjell på 16 /24 /32bit native så virker det som du har funnet en løsning på det m.h.t til DAC/SD-avspilleren din.
Men jeg er ikke overbevist om at oss andre som f.eks bruker 24bit USB DAC'er har et reelt problem..

Din endelige løsning ble jo da også det helt motsatte av ditt opprinnelige førsteinnlegg.
Legger man til "1" etter LSB i negative samples ved konvertering til 24/32bit så blir jo resultatet "ekte" (d.v.s falsk) 24/32bits data. Og da vil 16bits data avspilles som 24/32bits data, bare med kunstig presisjon i negative samples.
Og dette har IMHO ikke så mye med two's complement eller ikke. At n-bit audio representeres som 1 Signed + (n-1)bits har det alltid vært, iogmed waveformen er som den er :)
 
O

Oblivion

Gjest
Man skrev:
Om du hører forskjell på 16 /24 /32bit native så virker det som du har funnet en løsning på det m.h.t til DAC/SD-avspilleren din.
Men jeg er ikke overbevist om at oss andre som f.eks bruker 24bit USB DAC'er har et reelt problem..

Din endelige løsning ble jo da også det helt motsatte av ditt opprinnelige førsteinnlegg.
Legger man til "1" etter LSB i negative samples ved konvertering til 24/32bit så blir jo resultatet "ekte" (d.v.s falsk) 24/32bits data. Og da vil 16bits data avspilles som 24/32bits data, bare med kunstig presisjon i negative samples.
Og dette har IMHO ikke så mye med two's complement eller ikke. At n-bit audio representeres som 1 Signed + (n-1)bits har det alltid vært, iogmed waveformen er som den er :)
Ikke enkelt å forholde seg til for eksempel referater fra Wikipedia samtidig som en har "løsningen" i hodet...
Fordi MSB bitet blir invertert i forhold til resten av LSB bitene i forhold til two´s complement coden var det "real life" med MSB bit invertert jeg tenkte på da jeg skrev åpningsinnlegget.
Det er til tider slitsomt å måtte forholde seg til beskrivelser fra andre som har lest første del av teorien når jeg har hele funksjons rekkefølgen som også inkluderer del to av teorien.
Det tryggeste er vel å trekke seg rolig tilbake la "kritikerne" overta her på sentralen...
 

nma

Hi-Fi freak
Ble medlem
07.12.2003
Innlegg
4.696
Antall liker
518
Torget vurderinger
1
Kritikere?
Det er du som indirekte hevder av en samlet bransje tar feil, og feilsiterer fra wiki. Da må det være lov å spørre deg om grunnlaget for påstanden din.

Noen linjer nedenfor sitatet ditt står det "Similarly, when a two's-complement number is shifted to the right, the most-significant bit, which contains magnitude and the sign information, must be maintained. However when shifted to the left, a 0 is shifted in. These rules preserve the common semantics that left shifts multiply the number by two and right shifts divide the number by two."
 

oyvine

Hi-Fi entusiast
Ble medlem
03.11.2005
Innlegg
184
Antall liker
1
Oblivion skrev:
Hvis du tenker deg om og sjekker en gang til og ikke tenker rene binære verdier eller "one´s compliment code",
men "two´s compliment code" vil du forstå det.
Hei,
jeg snubla over denne tråden i arkivet og klarer bare ikke å la den ligge. Jeg har finlest tråden et par ganger for å se om det er noe jeg har misset. Håper et lite eksempel kan hjelpe på forståelsen. I eksemplene har jeg økt fra 2 til 4 bit bredde:

Enerkomplement:

Binærverdi Desimalverdi Desimalverdi*4 Binærverdi(enerkomplement)
00 0 0 0000
01 1 4 0100
10 -0 -0 1000
11 -1 -4 1100


Toerkomplement:

Binærverdi Desimalverdi Desimalverdi*4 Binærverdi(toerkomplement)
00 0 0 0000
01 1 4 0100
10 -2 -8 1000
11 -1 -4 1100


Dersom du padder med MSB istedet for med 0, får du (Oblivionkomplement):

Binærverdi Desimalverdi Binærverdi*4(pad=MSB) Oblivion sin skalerte verdi
00 0 0000 0(korrekt)
01 1 0100 4(korrekt)
10 -2 1011 -5(skulle vært -8)
11 -1 1111 -1(skulle vært -4)


Det skal paddes med 0 i LSB for både ener og toerkomplement dersom bit-bredden skal økes. Dersom dette ikke gir riktig resultat må det være en bug eller grov tilnærming i DAC-en et sted.

Hilsen,
Øyvin Eikeland
 

coolbiz

Hi-Fi freak
Ble medlem
31.03.2006
Innlegg
9.169
Antall liker
4.758
Sted
Sydvestlandet
Torget vurderinger
2
Jeg fattet interesse for dette og måtte børste støvet av min gamle HP-16C som kan regne i toerkomplement binærdata direkte, for å kjøre gjennom noen konverteringer og håndkontrollere. Kan ikke med min beste vilje skjønne at denne konverteringen fra 16 bits til større ordlengde er inkorrekt med hensyn til håndteringen av toerkomplement dataene. Toerkomplement representasjon ble jo utviklet nettopp for bl.a. å muliggjøre multiplikasjon med 2n som en enkel bitskift-operasjon.

Derimot ser det for mitt halvstuderte hode ut som om Oblivion har rett i at dersom denne konverteringen (bitskift + padding med '0') er alt som gjøres, ender man opp med et signal der hele waveformen er 1/2 LSB (16-bits LSB, altså) feil i nivå. Hvordan dette faktisk er implementert i ESS' eller andre produsenters konvertere har jeg ingen formening om. Det virker litt underlig at ikke konstruktørene har tenkt på dette.

Et interessant eksperiment for oss med 24-bits DACer og mulighet for å spille av 24-bits data med PC, Squeezebox o.l. kunne muligens være å sammenligne lyden av 16-bits lydfiler (slik at ordlengdekonvertering skjer i DACen), med 24-bits versjoner av de samme lydfilene der man har brukt f.eks. SoX for å konvertere fra 16 til 24 bits vha. ren bitskift og padding. Låter det forskjellig, gjør DACen noe riktig. Tror jeg..
 

Bx

Bransjeaktør
Ble medlem
04.08.2005
Innlegg
8.852
Antall liker
4.281
coolbiz skrev:
Derimot ser det for mitt halvstuderte hode ut som om Oblivion har rett i at dersom denne konverteringen (bitskift + padding med '0') er alt som gjøres, ender man opp med et signal der hele waveformen er 1/2 LSB (16-bits LSB, altså) feil i nivå. Hvordan dette faktisk er implementert i ESS' eller andre produsenters konvertere har jeg ingen formening om. Det virker litt underlig at ikke konstruktørene har tenkt på dette.
Det man må huske på her, er at det analoge nullpunktet til en 24 bit dac ligger litt høyere enn til en 16 bit dac.

Jeg bruker sikkert ikke korrekt terminologi her. Så jeg må kanskje forklare hva jeg mener med nullpunkt. En DAC kan ses på som en positiv spenningsregulator som leverer spenninger mellom 0 og 2V alt ettersom hvilken digital verdi som kommer inn. Så justerer man spenningsnivåene til slutt slik at tallet null inn gir 0V ut, dvs Fjerne DC. Men før man fjerner DC:

Når det største negative tallet som DAC-en kan håndtere kommer inn, så vil en slik DAC levere en 0 V ut. Når det største positive tallet kommer inn, vil DAC-en levere 2 V ut. Når null kommer inn vil DAC-en ikke levere nøyaktig 1V ut. Fordi det er alltid ett flere positive tall enn negative tall vi har til rådighet.

En 24 bit dac har et nullpunkt som ligger høyere, og nærmere Vmax / 2 enn en 16 bit dac.

Akkurat som en 3 bit dac har høyere nullpunkt enn en 2 bit dac.

2 bit:

00 = -1
01 = 0
10
11 = +2

Nullpunkt = 1/3 av Vmax

3 bit:

000 = -3
001
010
011 = 0
100
101
110
111 +4

Nullpunkt = 3/7 av Vmax

Det samme skjer når man går fra 16 bit DA til 24 bit DA. Nullpunktet flytter seg nærmere midten.

Men dette er en egenskap med selve DA konverteren og har ingen ting med selve signalet å gjøre. 24 bit konvertere SKAL ha høyere spenning på nullpunktet enn 16 bit konvertere.

Oblivions konvertering endrer kurveformen på det som kommer ut av konverteren. Den øker avstanden mellom positive og negative verdier med en konstant størrelse. Hvis det er en sinus som går inn, så er det en sinusbølge med strekkmerker på midten som kommer ut. De svake partiene av sinusen blir relativt sett forsterket svært mye mer enn de sterke partiene. Et annet ord for dette er komprimering. Det kan godt hende enkelte synes dette låter bedre fra tid til annen. Kanskje akustikken i opptaket kommer tydeligere fram? Det er jo også mange som liker komprimering generelt sett.

Konverteringen introduserer også en negative DC komponent, ettersom alle negative verdier er blitt øket mens de positive er uendret. Og som alltid når man endrer kurveformen så introduserer man harmonisk forvrengning.

Hvis man derimot gjør det etter boka, dvs 0-padder både positive og negative verdier, så beholder man kurveformen og flytter nullpunktet oppover. Og det er akkurat dette 24 bit dac-en trenger for å levere en korrekt analog kurveform som er fri for DC.
 
O

Oblivion

Gjest
Bx skrev:
coolbiz skrev:
Derimot ser det for mitt halvstuderte hode ut som om Oblivion har rett i at dersom denne konverteringen (bitskift + padding med '0') er alt som gjøres, ender man opp med et signal der hele waveformen er 1/2 LSB (16-bits LSB, altså) feil i nivå. Hvordan dette faktisk er implementert i ESS' eller andre produsenters konvertere har jeg ingen formening om. Det virker litt underlig at ikke konstruktørene har tenkt på dette.
Det man må huske på her, er at det analoge nullpunktet til en 24 bit dac ligger litt høyere enn til en 16 bit dac.

Jeg bruker sikkert ikke korrekt terminologi her. Så jeg må kanskje forklare hva jeg mener med nullpunkt. En DAC kan ses på som en positiv spenningsregulator som leverer spenninger mellom 0 og 2V alt ettersom hvilken digital verdi som kommer inn. Så justerer man spenningsnivåene til slutt slik at tallet null inn gir 0V ut, dvs Fjerne DC. Men før man fjerner DC:

Når det største negative tallet som DAC-en kan håndtere kommer inn, så vil en slik DAC levere en 0 V ut. Når det største positive tallet kommer inn, vil DAC-en levere 2 V ut. Når null kommer inn vil DAC-en ikke levere nøyaktig 1V ut. Fordi det er alltid ett flere positive tall enn negative tall vi har til rådighet.

En 24 bit dac har et nullpunkt som ligger høyere, og nærmere Vmax / 2 enn en 16 bit dac.

Akkurat som en 3 bit dac har høyere nullpunkt enn en 2 bit dac.

2 bit:

00 = -1
01 = 0
10
11 = +2

Nullpunkt = 1/3 av Vmax

3 bit:

000 = -3
001
010
011 = 0
100
101
110
111 +4

Nullpunkt = 3/7 av Vmax

Det samme skjer når man går fra 16 bit DA til 24 bit DA. Nullpunktet flytter seg nærmere midten.

Men dette er en egenskap med selve DA konverteren og har ingen ting med selve signalet å gjøre. 24 bit konvertere SKAL ha høyere spenning på nullpunktet enn 16 bit konvertere.

Oblivions konvertering endrer kurveformen på det som kommer ut av konverteren. Den øker avstanden mellom positive og negative verdier med en konstant størrelse. Hvis det er en sinus som går inn, så er det en sinusbølge med strekkmerker på midten som kommer ut. De svake partiene av sinusen blir relativt sett forsterket svært mye mer enn de sterke partiene. Et annet ord for dette er komprimering. Det kan godt hende enkelte synes dette låter bedre fra tid til annen. Kanskje akustikken i opptaket kommer tydeligere fram? Det er jo også mange som liker komprimering generelt sett.

Konverteringen introduserer også en negative DC komponent, ettersom alle negative verdier er blitt øket mens de positive er uendret. Og som alltid når man endrer kurveformen så introduserer man harmonisk forvrengning.

Hvis man derimot gjør det etter boka, dvs 0-padder både positive og negative verdier, så beholder man kurveformen og flytter nullpunktet oppover. Og det er akkurat dette 24 bit dac-en trenger for å levere en korrekt analog kurveform som er fri for DC.
Bernt jeg undrer meg: er det er MULIG å programmere tall manipulasjoner korrekt i Audiolense når du lager slike eksempler og forklaringer ???

Under har jeg tatt dine eksempler og lagt inn med rødt de VIRKELIGE verdiene dine 2 og 3 bit data egentlig representerer sett i forhold til en DAC og two´s compliment code:

2 bit:

00 = -1 => 0
01 = 0 => +1
10 => -2
11 = +2 => -1

Nullpunkt = 1/3 av Vmax

3 bit:

000 = -3 => 0
001 => +1
010 => +2
011 = 0 => +3
100 => -4
101 => -3
110 => -2
111 +4 => -1

Nullpunkt = 3/7 av Vmax
Under her har jeg lagt inn 8 bit data og de verdiene de egentlig representerer som signed eller om du vil - two´s compliment:

most-significant bit
0 1 1 1 1 1 1 1 = 127
0 1 1 1 1 1 1 0 = 126
0 0 0 0 0 0 1 0 = 2
0 0 0 0 0 0 0 1 = 1
0 0 0 0 0 0 0 0 = 0
1 1 1 1 1 1 1 1 = ?1
1 1 1 1 1 1 1 0 = ?2
1 0 0 0 0 0 0 1 = ?127
1 0 0 0 0 0 0 0 = ?128
8-bit two's-complement integers

Det underlige er at du ikke har fått med deg det faktum at de lyd data som en DAC normalt mottar er two´s compliment code


Under her har jeg lagt inn 8 bit data og de verdiene de egentlig representerer som unsigned:

most-significant bit
0 1 1 1 1 1 1 1 = 127
0 1 1 1 1 1 1 0 = 126
0 0 0 0 0 0 1 0 = 2
0 0 0 0 0 0 0 1 = 1
0 0 0 0 0 0 0 0 = 0
1 1 1 1 1 1 1 1 = 255
1 1 1 1 1 1 1 0 = 254
1 0 0 0 0 0 0 1 = 129
1 0 0 0 0 0 0 0 = 128
8-bit unsigned integers

Så gjennstår det følgende for å kunne forstå hvordan en DAC behandler den two´s compliment CODE den mottar:

Når en LSB ekstender et 8-bit tall til for eksempel 9-bit MÅ en forstå at det er 0.5 desimalt (eller en verdi som er lavere enn det den laveste av de orginale 8-bit representerte) en legger til eller trekker fra og IKKE at 127 desimalt blir til 255 desimalt etc...
Det er tross alt en bit som representerer lavere verdier enn den orginale LSB...

Når jeg i eksemplene under har skrevet en "." mellom 8-ende og 9-ende bit er det ikke float (floating point),
men kun for å markere at den LSB ekstendede bit representerer en verdi på 0.5 - altså en verdi mindre enn 1 eller den verdi som den orginale LSB har/hadde...


Hvis et 8-bit tall blir LSB ekstended til 9-bit korrekt med "0" for positive og "1" for negative samples blir det som følgende:

most-significant bit Extended
0 1 1 1 1 1 1 1 . 0 = 127
0 1 1 1 1 1 1 0 . 0 = 126
0 0 0 0 0 0 1 0 . 0 = 2
0 0 0 0 0 0 0 1 . 0 = 1
0 0 0 0 0 0 0 0 . 0 = 0
1 1 1 1 1 1 1 1 . 1 = ?1
1 1 1 1 1 1 1 0 . 1 = ?2
1 0 0 0 0 0 0 1 . 1 = ?127
1 0 0 0 0 0 0 0 . 1 = ?128
8-bit two's-complement integers ekstended with one LSB


Hvis et 8-bit tall blir LSB ekstended til 9-bit korrekt med "0" for positive og "1" for negative samples blir det som følgende:

* (lagt til for å vise økt linjaritet ved 9-bit oppløsning med ellers korrekt LSB extending)

most-significant bit Extended
0 1 1 1 1 1 1 1 . 0 = 127
0 1 1 1 1 1 1 0 . 0 = 126
0 0 0 0 0 0 1 0 . 0 = 2
0 0 0 0 0 0 0 1 . 1 = 1.5 *
0 0 0 0 0 0 0 1 . 0 = 1
0 0 0 0 0 0 0 0 . 1 = 0.5 *
0 0 0 0 0 0 0 0 . 0 = 0
1 1 1 1 1 1 1 1 . 0 = ?0.5 *
1 1 1 1 1 1 1 1 . 1 = ?1
1 1 1 1 1 1 1 0 . 0 = ?1.5 *
1 1 1 1 1 1 1 0 . 1 = ?2
1 0 0 0 0 0 0 1 . 1 = ?127
1 0 0 0 0 0 0 0 . 1 = ?128
8-bit two's-complement integers ekstended with one LSB


Hvis et 8-bit tall blir LSB ekstended til 9-bit med "0" for både positive og negative samples blir det følgende feil:

most-significant bit Extended
0 1 1 1 1 1 1 1 . 0 = 127
0 1 1 1 1 1 1 0 . 0 = 126
0 0 0 0 0 0 1 0 . 0 = 2
0 0 0 0 0 0 0 1 . 0 = 1
0 0 0 0 0 0 0 0 . 0 = 0
1 1 1 1 1 1 1 1 . 0 = ?0.5
1 1 1 1 1 1 1 0 . 0 = ?1.5
1 1 1 1 1 1 1 0 . 0 = ?2.5
1 0 0 0 0 0 0 1 . 0 = ?127.5
1 0 0 0 0 0 0 0 . 0 = ?128.5
8-bit two's-complement integers ekstended with one LSB



Hvis et 8-bit tall blir LSB ekstended til 9-bit med "1" for både positive og negative samples blir det følgende feil:

most-significant bit Extended
0 1 1 1 1 1 1 1 . 1 = 127.5
0 1 1 1 1 1 1 0 . 1 = 126.5
0 0 0 0 0 0 1 0 . 1 = 2.5
0 0 0 0 0 0 0 1 . 1 = 1.5
0 0 0 0 0 0 0 0 . 1 = 0.5
1 1 1 1 1 1 1 1 . 1 = ?1
1 1 1 1 1 1 1 0 . 1 = ?2
1 0 0 0 0 0 0 1 . 1 = ?127
1 0 0 0 0 0 0 0 . 1 = ?128
8-bit two's-complement integers ekstended with one LSB


Det er fullt mulig at jeg tidligere har forklart / uttrykt meg utydlig eller tvetydig, og det kan skyldes at jeg ikke "tenker" paste / kopi fra wikipedia eller lignende, men at jeg i tankene er inne i hardwaren i en DAC og forklarer ut fra den fysiske virkemåten.

Resten av "forklaringen" din tror jeg vi forbigår i stillhet.....
 
Topp Bunn