napsi skrev: Ghammel & Suhr skrev: Fil systemer benytter naturligvis også CRC så man kan være sikker på at data læses korrekt og ens programmer kan køre korrekt. Igen, hvis du kan læse det her, så har jeg ret :D Ja, men hvad så med audio data - dem forholder du dig ikke til... Audio-data er en delmængde af data. Så enkelt kan det siges. Audio-data er den venlige delmængde, mens program-data er meget utilgivende overfor fejl, men begge behandles med samme kærlige omtanke fra filsystemets side. :)

Du er mere diplomatisk end jeg

Ghammel & Suhr skrev: napsi skrev: Øm.. Hvis man mener at TCP pakker ikke har checksum på data-indholdet, så tager man fejl. "Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. " - TCP Protocol Specification Hele ideen med TCP er at skabe hvad man kalder "en pålidelig kanal". En sådan skal garatere at data når frem uden fejl, i rigtig rækkefølge og at gentagelser (retransmissions) bliver sorteret fra. TCP kan naturligvis ikke garanterer at data når frem i alle tilfælde - hvis man f.eks. hiver netværksstikket ud - men der prøves et stykke tid, hvorefter den tilknyttede applikation gøres opmærksom på problemet. Har man ikke brug for en pålidelig kanal bruger man UDP i stedet, som kun har checksum på headers og ikke udfører retransmission. Det er intet problem at lave lossless komprimering, der er masser af formatter der gør det, f.eks. ZIP og RAR, som de fleste nok kender. (Det ville være katastrofalt hvis de introducerede fejl.) Vil man vide hvilke teknikker man bruger, kan man følge kurset på datalogi. :) Men det er ikke svært at forestille sig meget simple algoritmer til at gøre f.eks. teksten i en bog mindre uden tab (Swap korte og lange ord, der forekommer med passende frekvenser). Så der er umiddelbart ingen grund til at være mistroisk overfor FLAC. Jamen, det er da fint nok, Numsi Nu skal du blot lære at skelne mellem de forskellige typer data, så skal det nok gå fint altsammen Nej, helt alvorligt, så har du helt ret, men kun så længe det IKKE handler om audio data. Disse opfører sig en smule anderledes. Hvis du f.eks. forestiller dig (og det er KUN et metaforisk eksempel, det her), at der skal en spænding på 60 pct. til for at producere en data bit, så vil de samme 60 pct. producere en hørbar forringelse, når det kommer til audio. Audiodata er mere skrøbelige. Prøv evt. at tage en snak med fysikerne om det, det vil du nok ikke fortryde Prøv evt. at dykke lidt ned i "protocol tunneling"

Synes det er lidt mærkeligt at tale ned til folk, omkring ting man ikke forstår. Jeg har personligt brugt 15 ECTS-point på at studere netværksprotokoller, og jeg kan garantere dig for at TCP er fuldtændig ligeglad med hvad du sender - al data håndteres på samme måde. Abstraktion er et koncept vi er meget glade for i datalogiens verden. :)

Omkring skrøbelighed vil jeg mene program-data er langt mere skrøbeligt. Èn forkert bit kan være katastrofalt. Det samme kan nok ikke siges om audio-data, men TCP er som sagt lige påpasselig med begge, meget naturligt i det den ikke kender forskel. :)

Var det dig der engang mente at Page Faults introducerer forkerte bits under programudførsel? :D

Skyblue skrev: Ghammel & Suhr skrev: Skyblue skrev: Oi, nu bliver der lukket så meget l**t ud man knap fatter det.. LOL Nå Men Både tcp/ip, firewire og de fleste fornuftige protocoller, bruger CRC checksummer på data for at sikre at tingene kommer over i korrekt tilstand. Det fungerer perfekt, hvilket man kan konstatere ved at læse det her indlæg. Det er derfor intet belæg for at tro at der er datatab ved overførsler af nogen art. Kommer du alting i små, bit-perfekte kasser? Det handler ikke om at "tro", alene om, at jeg har videregivet en mængde potentielle fejlkilder, som du så kan forholde dig til eller lade være. Det har jeg så gjort. Der er intet at komme efter. Den eneste fejlkilde som findes er i selve cd formatet, se nedenfor. Hvis blot det var så enkelt... Det er korrekt at der ved aflæsning af cd'ere kan være forskel på aflæsningerne. Det skyldes at cd audio formatet ikke anvender CRC og at der specielt ved hjemme brænding af cd'ere kan forekomme fejl. Det er CD formatets problem og har intet med computere at gøre. Det betyder også at der kan være forskel på cd drev's formåen til at læse skiven korrekt. Bemærk iøvrigt at CDROM formatet er anderledes og indeholder CRC fordi at cd audio formatet var for ringe. Hvorfor man ikke forlængst har smidt cd audio i havet er mig en gåde. Fil systemer benytter naturligvis også CRC så man kan være sikker på at data læses korrekt og ens programmer kan køre korrekt. Igen, hvis du kan læse det her, så har jeg ret :D Ja, men hvad så med audio data - dem forholder du dig ikke til... Filsystemet er temmelig ligeglad med om data er af den ene eller anden slags. Det er bare 0'er og 1'ere. Filsystemet har ingen ide om hvad slags data det er. Programdata og audiodata er IRL to vidt forskellige størrelser, og det var sådan set pointen... Data på harddiske lagres i sektorer og størrelsen af disse bestemmes faktisk af formatteringen. Det er rigtigt at man så inddeler sectors i clusters og hvad ved jeg, men det ændrer ikke på at du havde ret i mindst en sætning, selvom du ikke selv troede på det. Er du sikker på at du arbejder med det her til daglig? Ikke korrekt. Det er faktisk stik modsat. Det burde du vide, hvis du selv arbejder med det til daglig Jamen prøv så at læse den her: http://www.ntfs.com/ntfs-partition-boot-sector.htm Eller http://en.wikipedia.org/wiki/File_Allocation_Table "To reduce the management complexity, disk space is allocated to files in contiguous groups of hardware sectors called clusters." Yeps, clusters som nederste hieraki, ikke sektorer. Mht. windows 15 bit nedsampling, så har jeg ikke noget kendskab til dette. Men her kan man se et eksempel på et api kald (http://www.borg.com/~jglatt/tech/lowaud.htm) og der ser det da ud som om man ikke er restrikseret til 16 bit, man kan selv bestemme. Please kom med en reference, for det har du brug for, for at bevare et lille niveau af troværdighed her. Nårrhhh... EU har eller netop givet MS en bøde i mia. størrelsen for netop ikke at ville give adgang til deres API's Den sag handler om at Microsoft har deres egne hemmelige api'er som ikke fejler eller opfører sig sært. ??????? Den sag er da vist forøvrigt helt tilbage fra word perfects tid er den ikke? Næj. Endelig behøver man jo ikke at bruge windows. Man kan jo bare købe sin egen processor og skrive sin egen software. Det er jo det som f.eks. Lyngdorf har gjort hvor alt er digitalt. Men det er jo bare en computer forklædt som forstærker. Nåja en temmelig uhøfligt indlæg, men there you are. Jeg synes der er alt for meget voodoo og bortforklaringer i hifi Hæ-hæ, og her er du selv kommet med nogle af dem   og det her har jeg så meget forstand på at jeg ikke bare ku sidde det overhørigt. Her suhr, please svar igen, men denne gang med link referencer til dine påstande. Dem jeg lige ku checke på google har ikke holdt vand overhovedet. Men der kan selvfølgelig være noget jeg har overset. Hvis du nu kunne modbevise noget med andet end floskler, så kunne det være interessant... Jamen se link og se om du kan nogen selv Æw-bæw-bussemand.... Sig mig, tror du denne tråd er oprettet som en længde-p***er konkurrence...? Den er oprettet, fordi der er en række dokumenterede forhold omkring dataintegritet og overførselsprotokoller, som godt kunne trænge til at se dagens lys, før vi alle er skidt i småstykker af branchen Dette indbefatter selvsagt en del problematikker, som ikke alle har kendskab til - og det kan ikke være meget anderledes. Så kom i stedet frisk med nogle seriøse bud på, hvordan vi løser disse problematikker. Dette kræver selvsagt, at man først sætter sig en smule ind i problematikkerne, men det skulle vel være en smal sag, ikk'`

__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

napsi skrev: Ghammel & Suhr skrev: napsi skrev: Øm.. Hvis man mener at TCP pakker ikke har checksum på data-indholdet, så tager man fejl. "Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. " - TCP Protocol Specification Hele ideen med TCP er at skabe hvad man kalder "en pålidelig kanal". En sådan skal garatere at data når frem uden fejl, i rigtig rækkefølge og at gentagelser (retransmissions) bliver sorteret fra. TCP kan naturligvis ikke garanterer at data når frem i alle tilfælde - hvis man f.eks. hiver netværksstikket ud - men der prøves et stykke tid, hvorefter den tilknyttede applikation gøres opmærksom på problemet. Har man ikke brug for en pålidelig kanal bruger man UDP i stedet, som kun har checksum på headers og ikke udfører retransmission. Det er intet problem at lave lossless komprimering, der er masser af formatter der gør det, f.eks. ZIP og RAR, som de fleste nok kender. (Det ville være katastrofalt hvis de introducerede fejl.) Vil man vide hvilke teknikker man bruger, kan man følge kurset på datalogi. :) Men det er ikke svært at forestille sig meget simple algoritmer til at gøre f.eks. teksten i en bog mindre uden tab (Swap korte og lange ord, der forekommer med passende frekvenser). Så der er umiddelbart ingen grund til at være mistroisk overfor FLAC. Jamen, det er da fint nok, Numsi Nu skal du blot lære at skelne mellem de forskellige typer data, så skal det nok gå fint altsammen Nej, helt alvorligt, så har du helt ret, men kun så længe det IKKE handler om audio data. Disse opfører sig en smule anderledes. Hvis du f.eks. forestiller dig (og det er KUN et metaforisk eksempel, det her), at der skal en spænding på 60 pct. til for at producere en data bit, så vil de samme 60 pct. producere en hørbar forringelse, når det kommer til audio. Audiodata er mere skrøbelige. Prøv evt. at tage en snak med fysikerne om det, det vil du nok ikke fortryde Prøv evt. at dykke lidt ned i "protocol tunneling" Synes det er lidt mærkeligt at tale ned til folk, omkring ting man ikke forstår. Jeg har personligt brugt 15 ECTS-point på at studere netværksprotokoller, og jeg kan garantere dig for at TCP er fuldtændig ligeglad med hvad du sender  NETOP! - al data håndteres på samme måde. Abstraktion er et koncept vi er meget glade for i datalogiens verden. :) Omkring skrøbelighed vil jeg mene program-data er langt mere skrøbeligt. Èn forkert bit kan være katastrofalt. Det samme kan nok ikke siges om audio-data, men TCP er som sagt lige påpasselig med begge, meget naturligt i det den ikke kender forskel. :) Var det dig der engang mente at Page Faults introducerer forkerte bits under programudførsel? :D Nej, det var faktisk dig, der (forgæves) forsøgte at skyde mig netop dette i skoene - ganske som du gør det nu Prøv nu at få en snak med de fysikere. Og dyk lidt ned i noget tunneling. Jeg tror du vil blive lidt overrasket

__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

Ghammel & Suhr skrev: napsi skrev: Ghammel & Suhr skrev: napsi skrev: Øm.. Hvis man mener at TCP pakker ikke har checksum på data-indholdet, så tager man fejl. "Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. " - TCP Protocol Specification Hele ideen med TCP er at skabe hvad man kalder "en pålidelig kanal". En sådan skal garatere at data når frem uden fejl, i rigtig rækkefølge og at gentagelser (retransmissions) bliver sorteret fra. TCP kan naturligvis ikke garanterer at data når frem i alle tilfælde - hvis man f.eks. hiver netværksstikket ud - men der prøves et stykke tid, hvorefter den tilknyttede applikation gøres opmærksom på problemet. Har man ikke brug for en pålidelig kanal bruger man UDP i stedet, som kun har checksum på headers og ikke udfører retransmission. Det er intet problem at lave lossless komprimering, der er masser af formatter der gør det, f.eks. ZIP og RAR, som de fleste nok kender. (Det ville være katastrofalt hvis de introducerede fejl.) Vil man vide hvilke teknikker man bruger, kan man følge kurset på datalogi. :) Men det er ikke svært at forestille sig meget simple algoritmer til at gøre f.eks. teksten i en bog mindre uden tab (Swap korte og lange ord, der forekommer med passende frekvenser). Så der er umiddelbart ingen grund til at være mistroisk overfor FLAC. Jamen, det er da fint nok, Numsi Nu skal du blot lære at skelne mellem de forskellige typer data, så skal det nok gå fint altsammen Nej, helt alvorligt, så har du helt ret, men kun så længe det IKKE handler om audio data. Disse opfører sig en smule anderledes. Hvis du f.eks. forestiller dig (og det er KUN et metaforisk eksempel, det her), at der skal en spænding på 60 pct. til for at producere en data bit, så vil de samme 60 pct. producere en hørbar forringelse, når det kommer til audio. Audiodata er mere skrøbelige. Prøv evt. at tage en snak med fysikerne om det, det vil du nok ikke fortryde Prøv evt. at dykke lidt ned i "protocol tunneling" Synes det er lidt mærkeligt at tale ned til folk, omkring ting man ikke forstår. Jeg har personligt brugt 15 ECTS-point på at studere netværksprotokoller, og jeg kan garantere dig for at TCP er fuldtændig ligeglad med hvad du sender  NETOP! - al data håndteres på samme måde. Abstraktion er et koncept vi er meget glade for i datalogiens verden. :) Omkring skrøbelighed vil jeg mene program-data er langt mere skrøbeligt. Èn forkert bit kan være katastrofalt. Det samme kan nok ikke siges om audio-data, men TCP er som sagt lige påpasselig med begge, meget naturligt i det den ikke kender forskel. :) Var det dig der engang mente at Page Faults introducerer forkerte bits under programudførsel? :D Nej, det var faktisk dig, der (forgæves) forsøgte at skyde mig netop dette i skoene - ganske som du gør det nu Prøv nu at få en snak med de fysikere. Og dyk lidt ned i noget tunneling. Jeg tror du vil blive lidt overrasket

Hehe, nej tror nu den ide må stå for din egen regning, hehe. Jeg ville bestemt aldrig sige noget så forrykt.

"Netop" - som I, at vi er enige om at lyd-data får samme omgang fejl-håndtering, som alt andet data? :)

Jeg tror ikke fysikere ved noget særligt om hvordan TCP fungerer. Så du må lige motivere hvad vi skal med dem i en diskussion om TCP? - Eller hvad er det du vil snakke om?

"Programdata og audiodata er IRL to vidt forskellige størrelser, og det var sådan set pointen..."

- Nej - de består begge af 0'er og 1'er. Du kan i princippet køre en lydfil som program eller omvendt afspille et program som en sang.  Det ville gå galt men sådan er det.

"To reduce the management complexity, disk space is allocated to files in contiguous groups of hardware sectors called clusters."

Yeps, clusters som nederste hieraki, ikke sektorer.

Æh.. Nej. Filer består af clusters som igen består af sectorer. Sectorer er dermed nederst.

Æw-bæw-bussemand.... Sig mig, tror du denne tråd er oprettet som en længde-p***er konkurrence...?

Den er oprettet, fordi der er en række dokumenterede forhold omkring dataintegritet og overførselsprotokoller, som godt kunne trænge til at se dagens lys, før vi alle er skidt i småstykker af branchen

Dette indbefatter selvsagt en del problematikker, som ikke alle har kendskab til - og det kan ikke være meget anderledes.

Jeg har kun mødt et fåtal genier i min tid, som var så gode at andre ikke forstod dem. Det muligt at du er sådan en men det ville unægtelig hjælpe din sag, hvis du kunne finde nogen andre i hele verden som delte dine bekymringer. Please kom med et link til nogen andre som mener det samme, eller også må du bare ha det.


Så kom i stedet frisk med nogle seriøse bud på, hvordan vi løser disse problematikker.

Dette kræver selvsagt, at man først sætter sig en smule ind i problematikkerne, men det skulle vel være en smal sag, ikk'`

Jeg har da skrevet min egen sektor writer engang, så jeg forsikre dig om at harddiske har sektorer

Nuvel, du har ikke kunnet produceret så meget som et æsel der er enig med dig. Og alle de oplysninger du har givet som jeg selv umiddelbart kunne checke med en google søgning har været forkerte. Hvis du ikke selv er istand til at google eller læse de links jeg har givet, så forstår jeg bedre din holdning. Men nu er det et komplet spild af tid. Du er velkommen til at have din egen holdning til hvordan harddiske fungerer. Fakta er tydeligvis ikke en del af den bagvedliggende verdensbillede. Jeg giver op

 

Skyblue skrev: Her suhr, please svar igen, men denne gang med link referencer til dine påstande. Dem jeg lige ku checke på google har ikke holdt vand overhovedet. Men der kan selvfølgelig være noget jeg har overset.

Ghammel & Suhr skrev: Hvis du nu kunne modbevise noget med andet end floskler, så kunne det være interessant...

G&S, det er vist det man kalder omvendt bevisbyrde...

Du bruger kolossal meget plads på at komme med nogen hidtil u-underbyggede påstande. Når andre så beder dig dokumentere det på NOGEN som helst måde, så vender du bare spørgsmålet om og siger at det er dem der må bevise at du tager fejl. Det er vist ikke helt fair... 

Kan du f.eks. påvise hvad det helt præcis er for en forskel en PC skulle gøre på audio-data og enhver anden slags data..? Jeg mener det må være mere på sin plads at du dokumenterer denne påstand, snarere end at andre skal bevise at det IKKE er tilfældet.

P.s.: @alle: kan vi ikke slippe for det dér farvekodede helvede med røde, grønne, blå og andre eksotiske farver i skriften - det er TEMMELIG besværligt at holde rede i hvem der siger hvad.

Meget spænende debat, hvor det er tydeligt at ikke alle er enige. Jeg kan se på indlægene her de sidste par sider at, uhm, tiltaleformen? er ved at gå lidt ned ad. Kan vi ikke rette lidt op på det?

Blot en venlig opfordring - intet andet!

Fortsat god debat

Digitalitet er netop dét at man ikke behøver bekymre sig om mindre analoge forskelle, ubeagtet at platformen er analog; om den er det i det uendelige er der vist delte meninger om. Så hvorfor skal vi blande fysikerne ind i en debat om digital signaltransport?

Udfra hvad du tidligere har skrevet, Ghammel & Suhr, har jeg på fornemmelsen at du fokuserer på jitter, snarere end bitfejl, da det vist er lidt svært at dokumentere at bitfejl skulle være særligt forekommende for audio data. TCP/IP er komplet agnostisk overfor den ene eller den anden type data, det samme er din harddisk. Det der derimod måske kan være tale om, er måske at der kan forekomme mere jitter med TCP/IP end med andre protokoller, hvis det vel og mærke implementeres hovedløst.

Men vi skal vel ikke til at se på harddisken og små analoge fænomener i denne, når blot denne overfører data korrekt til en buffer.

Som med protokoller er digitalitet også en abstraktion.

Ghammel & Suhr skrev: ... Muligheden for fejl opstår imidlertid grundet den tætpakkede struktur moderne harddiske anvender. Og jow, nogle har nok allerede gættet, at der her er tale om en hidtil ikke særligt beskrevet form for jitter  Den tekniske beskrivelse af denne denne form for jitter er i fagsprog "sector smearing". I al korthed består dette af, at der sektorer imellem magnetisk afsmittes data. Altså i virkeligheden analog jitter fra et ellers "digitalt" medie (harddisken er reelt et analogt (magnetisk) medie). For at kunne forstå den fulde implikation af dette, henvises der høfligst til opbygningen af filsystemerne i Windows operativsystemer, hvis man vil vide mere. Anyway, så betyder dette i audio sammenhænge en yderligere forringelse af lydkvaliteten, da de på harddisken indlæste data således har en afsmitning på hverandre, modsat CD mediet, hvor data har en absolut (fikseret) form. Ooops! fristes man næsten til at sige  ...

Ja, ooops vil jeg da også sige.

Forklar lige hvorfor lyd er så meget mere skrøbeligt, når det er lagret som filer på en harddisk, end f.eks. JPEG billeder?

En lille fejl i et komprimeret billede, vil ses på langt mere end blot én enkelt pixel, da billedet ikke er lagret med informationer om hver enkelt pixel, på samme måde som bitmap.

Alligevel er det muligt at opbevare millioner af komprimerede fotos, uden at der er fejl alle vegne.
Harddiskene er altså sikre nok til at opbevare billedfiler, men ifølge dig, ikke lydfiler?

Hvad er det der gør lydfilerne så skrøbelige?
Jitter forefindes ikke i de oprindelige 16bit lydfiler (bortset fra den der introduceres under optageprocessen, og alligevel ikke kan fjernes), men opstår først når man enten oversampler, eller upsampler. Afspiller du dine 16bit lydfiler uden oversampling, vil der ikke forefindes jitter i lyden. Audio Note bruger denne teknik. Jitter er desuden noget den fejlbehæftede S/PDIF-standard tilfører. USB og TCP/IP laver ikke problemer af den karakter. Heller ikke i Windows.

Hvis denne sector smearing ødelægger lydfiler, hvordan er det så muligt at bruge programmerne på harddisken, og få styresystemet til at køre? Er det en særlig sector smearing, der kun findes der hvor der ligger lydfiler?

Hvis man er nervøs for om der er fejl i den lydfil man har rippet fra en CD, kan man bruge denne database:

http://www.accuraterip.com/

Det sikrer tillige at den CD man har, er i 100% perfekt stand, og uden ridser.
Det kan man ikke være sikker på, med en almindelig CD-afspiller, eller drev.

Sikkerheden er altså langt bedre ved ripning til harddisk, end ved afspilning fra et traditionelt drev.
Den software fejlkorrektion som programmet EAC bruger, kan også sagtens være bedre, end den standardsoftware der bruges i mange CD-afspillere. Rega siger at de har noget software der er bedre, end de andres, men det er en anden dikussion.

napsi skrev: Skyblue skrev: Ja jeg har også læst datalogi Napsi. Man kan ikke gardere sig mod fejl på disken eller fejllæsninger, men man kan detektere dem og rette dem til det korrekte, hvad du sikkert ved bedre end jeg. Det er lang tid siden jeg gik på DIKU :) Det er nok også hvad jeg vil kalde at gardere sig, men nej diske ikke er perfekte - Så det er godt at vi kan abstrahere deres fejl væk og blandt andet lave fejlfri komprimering og TCP transmissioner - ellers var der heller ikke meget sjovt ved at have en computer. :)

Her i vi nok stille og roligt ved at nå ind til sagens kerne.

De (jitter)fejl, der uværgerligt vil opstå ifm. aflæsningen vil blive transporteret videre (uanset selv progressiv fejlretning).

F.eks. bit-fejl i audiodata vil selvfølgelig blive interpoleret, og så taler vi så vidt jeg ved ikke længere om de oprindelige audiodata på mediet.

Interpolation er sådan set en oldtussegammel måde at tænke datakorrektion på, når det kommer til audio, netop af førnævnte årsag.



__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

Skyblue skrev: Jeg har da skrevet min egen sektor writer engang, så jeg forsikre dig om at harddiske har sektorer

Jeg har ikke på noget tidspunkt påstået, at harddiske ikke har sektorer. Har du lige fået juleferie fra Blå Stue, eller hwa'?



__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

xo skrev: Digitalitet er netop dét at man ikke behøver bekymre sig om mindre analoge forskelle, ubeagtet at platformen er analog; om den er det i det uendelige er der vist delte meninger om. Så hvorfor skal vi blande fysikerne ind i en debat om digital signaltransport? Udfra hvad du tidligere har skrevet, Ghammel & Suhr, har jeg på fornemmelsen at du fokuserer på jitter, snarere end bitfejl, da det vist er lidt svært at dokumentere at bitfejl skulle være særligt forekommende for audio data. TCP/IP er komplet agnostisk overfor den ene eller den anden type data, det samme er din harddisk. Det der derimod måske kan være tale om, er måske at der kan forekomme mere jitter med TCP/IP end med andre protokoller, hvis det vel og mærke implementeres hovedløst. Men vi skal vel ikke til at se på harddisken og små analoge fænomener i denne, når blot denne overfører data korrekt til en buffer. Som med protokoller er digitalitet også en abstraktion.

Nemmerli', hr. xo - gode pointer! 

Nogle bør blot passe en smule på, at "digitalitet" ikke går hen og bliver "analogt med" 

Fejl er ikke nødvendigvis deciderede bit-fejl. Man kan også betragte alt, hvad der ikke oprindeligt er på kildematerialet som fejl. Og det er netop, hvad jeg gør.

Ser vi dernæst på deciderede fejlaflæsninger (sker langt oftere, end de fleste forestiller sig), så vil der ved korrektionen (som erstatning for det oprindelige signal) være tale om en interpolation. Altså ikke en eksakt, men i stedet en tilnærmet værdi.

Er fejlene i lyden (jitter) først introduceret ved aflæsningen (og oftest forøget undervejs), så er de der, uanset hvad, og uanset hvad der måtte være af senere fejlretning.

Jitter i forbindelse med TCP/IP som transport protokol har jeg ikke hørt om, kun regulær datakorruption (det er jo også slemt nok ;-), så fortæl gerne noget mere om det. Det er nok ikke urealistisk, da jitter jo bliver mere eller mindre jævnt induceret i hele transportforløbet.

De fleste CD-ROM/DVD drev synes jeg i øvrigt er af så tilpas kummerlig kvalitet, at man bør se sig forholdsvis godt for, hvis man skal buge det til musik.

For den del år siden legede jeg med nogle maskiner til en kunde, og fik så den ide at sætte nogle specielle (hundedyre) teflon SCSI kabler på både CD drev og Harddisk. Selv om prisen på teflon-kablerne var mere end 10 gange så høj, så var den lydmæssige forbedring hver en øre værd. Forbedringen var klart bedre opløsning, flere detaljer, bedre rumgengivelse og i det hele taget renere lyd. ALtså typisk de samme ting der sker, når niveauet af jitter nedsættes. Generel dataoverførsel gik i øvrigt mellem 10 og 20 pct. op, afhængig af applikationen.

Desværre har jeg ikke set disse teflon kabler her i DK (markedet er vel for lille), så hermed en opfordring til en evt. medlæsende importør - og også gerne til ATA, tak 

Så overførselshastigheder set under et har jeg lige siden haft en mistanke om bliver reduceret, hvis der opstår jitter undervejs. Og tiden har kun vist det samme.

Hvis man har et ATA RAID system derhjemme med 4 diske, hvor alle drev er sat op som Master, kan man jo prøve at klippe den løsthængende sekundære kanal af kablet (tag først strømmen fra). Dette skulle også gerne give et mærkbart performance boost, omend det er i den mindre afdeling.

Mens det selvfølgelig er rigtigt, at der pricipielt ikke ændres på data undervejs, vil jitter-induceret data stadig fremstå som korrekte data hos diverse kontrol- og fejlretningsfunktioner. Og skulle der være enkelte fejl, vil de selvfølgelig også blive rettet. Men påvirkningen fra jitter - altså den skade jitter gør på lyden - vil imidlertid forblive intakt.

Hvis nogen kan fylde mere på her (f.eks. xo, napsi), så gør det gerne 


@Bumle: At jitter først skulle opstå ved up/oversampling er noget forchromet vås, sorry. Det opstår allerede ved aflæsningen af (lyd)data, stort set uanset mediet.

Lyddata er netop mere følsomme pga. den uundgåelige tilførsel af jitter fra CD-drev, kabler, ATA ift. SCSI, RAM, ja, sågar visse bundkort tilfører i sig selv så meget jitter og/eller inteferens, at det nærmest er til at hulke over.

Dernæst kommer vibrationerne fra såvel CD-drev som harddisk, og en ofte støjende SMPS hjælper heller ikke på problemet.

Så imens data i den perfekte verden blot er data, så ser virkeligheden imidlertid en smule anderledes ud - og det er lissom det, vi gerne skulle beskæftige os med her 

Nåhjah, så bruger "Accurate"Rip ganske som "E"AC en form for "gennemsnitsdatabase", hvorfor resultatet alt andet lige kun kan være netop et gennemsnit. Jeg forstår ikke helt, at folk falder for den slags marketingsbawl, men det er nok bare mig 

Få i stedet fat på Adaptec's Easy CD Creator v. 3.1, eller en af de tidlige versioner af WinOnCD. De lyder begge kanon hamrende godt i forhold til alt det andet nyt=godt, der er på markedet i dag, puh-bad 




__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

Ghammel & Suhr skrev: napsi skrev: Skyblue skrev: Ja jeg har også læst datalogi Napsi. Man kan ikke gardere sig mod fejl på disken eller fejllæsninger, men man kan detektere dem og rette dem til det korrekte, hvad du sikkert ved bedre end jeg. Det er lang tid siden jeg gik på DIKU :) Det er nok også hvad jeg vil kalde at gardere sig, men nej diske ikke er perfekte - Så det er godt at vi kan abstrahere deres fejl væk og blandt andet lave fejlfri komprimering og TCP transmissioner - ellers var der heller ikke meget sjovt ved at have en computer. :) Her i vi nok stille og roligt ved at nå ind til sagens kerne. De (jitter)fejl, der uværgerligt vil opstå ifm. aflæsningen vil blive transporteret videre (uanset selv progressiv fejlretning). F.eks. bit-fejl i audiodata vil selvfølgelig blive interpoleret, og så taler vi så vidt jeg ved ikke længere om de oprindelige audiodata på mediet. Interpolation er sådan set en oldtussegammel måde at tænke datakorrektion på, når det kommer til audio, netop af førnævnte årsag.

Hverken TCP eller harddiske tvinger nogen til at interpolere.

Hvis man vil implementere et såkalt synkront system, hvor præcis timing er vigtigt, så skal man som nævnt ikke benytte TCP, harddiske eller anden teknologi med hovedet under armen. Hverken TCP eller harddiske stiller nogen garantier mht til tid, men givet dagens enorme hastighed på både harddiske og netværk (i forhold til de små mængder data musik kræver), så er det en relativ smal sag at implementere transport, der kan bruges til systemet.

Hvis man vil, kan man jo idag flytte en hel CD (på harddisk) fra Sjælland til en buffer i Jylland på få sekunder - dermed er alle led fra harddisk til buffer altså væk i løbet af få sekunder. (Siemens har netop sat rekord ved at sende med en hastighed på 2 DVD'er/sekund over en strækning på 161km.) Venter du disse få sekunder (eller blot til første nummer er klar) med at gøre brug af bufferens data, ja så er alt før bufferen pludselig taget helt ud af systemet, og har altså ingen indflydelse på det der efterfølgende sker - specielt er tidsforhold ved læsning fra disk og under transporten "glemt". ... Med undtagelse af linjen, så er det endda ikke et dyrt system at bygge, og ved mere almene afstande er også linjen billig. :)

Ghammel & Suhr skrev: Nåhjah, så bruger "Accurate"Rip ganske som "E"AC en form for "gennemsnitsdatabase", hvorfor resultatet alt andet lige kun kan være netop et gennemsnit. Jeg forstår ikke helt, at folk falder for den slags marketingsbawl, men det er nok bare mig

Det eneste der ville give mening at gemme er en hash-værdi, som intet har med gennemsnit at gøre. En hash-værdi, laves af en hash-funktionen - en funktion som opfylder at det bl.a. er praktisk umuligt at finde kollisioner. En kollision er to forskellige input som giver samme output (hash-værdi). Der er intet marketingsbawl over dette, hash-funktioner bruges i vid udstrækning, blandt andet i kryptologiens verden til at gøre kryptosystemer sikre mod angreb. Disse funktioner er altså sikre mod bevidste angreb, og man bør nok ikke gamble sin formue på at tilfældigheder som ripping-fejl giver anledning til kollisioner i forhold til det korrekte rip.

Men du kan da prøve at lave sådan et par - et korrekt rip og et fejlbefængt, som kolliderer. Men det er nok spild af tid. Den dårligste funktion man bruger nu om dage er vist MD5, som har 128bit output. Jvf. birthday paradox skal du forvente at 18 trilliarder mennesker skal rippe cd'en forskelligt før der opstår én kollision. Vi er altså, givet klodens relativ lille befolkning, ret sikre på at to ens hash-værdier på AccurateRip faktisk skyldes to ens ripninger. :)

-- Så fik jeg lige kigget lidt på hvad de gør hos AccurateRip. Det er blot en 32bit CRC, så det er knap så hårdt at finde kollision som ved MD5. "Allerede" ved 65.536 forskellige rips af den samme cd, vil man forvente én kollision (ikke nødvendigvis en kollision med det korrekte rip - at det er lige netop det man kollidere med er sandsynligheden naturligvis endnu mindre for). :)

Ghammel & Suhr skrev: xo skrev: Digitalitet er netop dét at man ikke behøver bekymre sig om mindre analoge forskelle, ubeagtet at platformen er analog; om den er det i det uendelige er der vist delte meninger om. Så hvorfor skal vi blande fysikerne ind i en debat om digital signaltransport? Udfra hvad du tidligere har skrevet, Ghammel & Suhr, har jeg på fornemmelsen at du fokuserer på jitter, snarere end bitfejl, da det vist er lidt svært at dokumentere at bitfejl skulle være særligt forekommende for audio data. TCP/IP er komplet agnostisk overfor den ene eller den anden type data, det samme er din harddisk. Det der derimod måske kan være tale om, er måske at der kan forekomme mere jitter med TCP/IP end med andre protokoller, hvis det vel og mærke implementeres hovedløst. Men vi skal vel ikke til at se på harddisken og små analoge fænomener i denne, når blot denne overfører data korrekt til en buffer. Som med protokoller er digitalitet også en abstraktion. Nemmerli', hr. xo - gode pointer!  Nogle bør blot passe en smule på, at "digitalitet" ikke går hen og bliver "analogt med"  Fejl er ikke nødvendigvis deciderede bit-fejl. Man kan også betragte alt, hvad der ikke oprindeligt er på kildematerialet som fejl. Og det er netop, hvad jeg gør. Ser vi dernæst på deciderede fejlaflæsninger (sker langt oftere, end de fleste forestiller sig), så vil der ved korrektionen (som erstatning for det oprindelige signal) være tale om en interpolation. Altså ikke en eksakt, men i stedet en tilnærmet værdi. Er fejlene i lyden (jitter) først introduceret ved aflæsningen (og oftest forøget undervejs), så er de der, uanset hvad, og uanset hvad der måtte være af senere fejlretning. Jitter i forbindelse med TCP/IP som transport protokol har jeg ikke hørt om, kun regulær datakorruption (det er jo også slemt nok ;-), så fortæl gerne noget mere om det. Det er nok ikke urealistisk, da jitter jo bliver mere eller mindre jævnt induceret i hele transportforløbet. De fleste CD-ROM/DVD drev synes jeg i øvrigt er af så tilpas kummerlig kvalitet, at man bør se sig forholdsvis godt for, hvis man skal buge det til musik. For den del år siden legede jeg med nogle maskiner til en kunde, og fik så den ide at sætte nogle specielle (hundedyre) teflon SCSI kabler på både CD drev og Harddisk. Selv om prisen på teflon-kablerne var mere end 10 gange så høj, så var den lydmæssige forbedring hver en øre værd. Forbedringen var klart bedre opløsning, flere detaljer, bedre rumgengivelse og i det hele taget renere lyd. ALtså typisk de samme ting der sker, når niveauet af jitter nedsættes. Generel dataoverførsel gik i øvrigt mellem 10 og 20 pct. op, afhængig af applikationen. Desværre har jeg ikke set disse teflon kabler her i DK (markedet er vel for lille), så hermed en opfordring til en evt. medlæsende importør - og også gerne til ATA, tak  Så overførselshastigheder set under et har jeg lige siden haft en mistanke om bliver reduceret, hvis der opstår jitter undervejs. Og tiden har kun vist det samme. Hvis man har et ATA RAID system derhjemme med 4 diske, hvor alle drev er sat op som Master, kan man jo prøve at klippe den løsthængende sekundære kanal af kablet (tag først strømmen fra). Dette skulle også gerne give et mærkbart performance boost, omend det er i den mindre afdeling. Mens det selvfølgelig er rigtigt, at der pricipielt ikke ændres på data undervejs, vil jitter-induceret data stadig fremstå som korrekte data hos diverse kontrol- og fejlretningsfunktioner. Og skulle der være enkelte fejl, vil de selvfølgelig også blive rettet. Men påvirkningen fra jitter - altså den skade jitter gør på lyden - vil imidlertid forblive intakt. Hvis nogen kan fylde mere på her (f.eks. xo, napsi), så gør det gerne  @Bumle: At jitter først skulle opstå ved up/oversampling er noget forchromet vås, sorry. Det opstår allerede ved aflæsningen af (lyd)data, stort set uanset mediet. Lyddata er netop mere følsomme pga. den uundgåelige tilførsel af jitter fra CD-drev, kabler, ATA ift. SCSI, RAM, ja, sågar visse bundkort tilfører i sig selv så meget jitter og/eller inteferens, at det nærmest er til at hulke over. Dernæst kommer vibrationerne fra såvel CD-drev som harddisk, og en ofte støjende SMPS hjælper heller ikke på problemet. Så imens data i den perfekte verden blot er data, så ser virkeligheden imidlertid en smule anderledes ud - og det er lissom det, vi gerne skulle beskæftige os med her  Nåhjah, så bruger "Accurate"Rip ganske som "E"AC en form for "gennemsnitsdatabase", hvorfor resultatet alt andet lige kun kan være netop et gennemsnit. Jeg forstår ikke helt, at folk falder for den slags marketingsbawl, men det er nok bare mig  Få i stedet fat på Adaptec's Easy CD Creator v. 3.1, eller en af de tidlige versioner af WinOnCD. De lyder begge kanon hamrende godt i forhold til alt det andet nyt=godt, der er på markedet i dag, puh-bad

Lad os nu for en gangs skyld slå fast at når en bit er indlæst i en buffer så kan den ikke have nogen jitter.. der ikke noget der hedder en 1'er bit med lidt jitter. Når den er i bufferen har den ikke nogen tidsmæssig udstrækning og kan så selvsagt ikke have nogen jitter da det relaterer sig til timing.

Hvis der var jitter på signalet der blev indlæst i bufferen så kan der ske 2 ting:

1. jitteren var stor nok til 1 bit blev samplet 2 gange. Denne fejl vil i bufferen være umulig at skelne fra en bit-fejl i den bit som ikke blev samplet. Du har altså et bitmønster i din buffer UDEN jitter, men med bitfejl.

2. jitteren var ikke stor nok til at forstyre samplingen, der er ingen fejl. Du har altså et bitmønster i din buffer UDEN jitter og uden bitfejl.

På det næste led i kæden (fra en buffer til en anden buffer) er der således ikke andet jitter end det der er på selve det led. Jitter akkumuleres altså ikke igennem ledene.

Så skal man altså blot gå efter i hvert enkelt led ikke at køre med højere bushastighed end at den jitter der kan opstå ikke er for stor i forhold til en enkelt fase.

ArneBjarne skrev: Lad os nu for en gangs skyld slå fast at når en bit er indlæst i en buffer så kan den ikke have nogen jitter.. der ikke noget der hedder en 1'er bit med lidt jitter. Når den er i bufferen har den ikke nogen tidsmæssig udstrækning og kan så selvsagt ikke have nogen jitter da det relaterer sig til timing. Hvis der var jitter på signalet der blev indlæst i bufferen så kan der ske 2 ting: 1. jitteren var stor nok til 1 bit blev samplet 2 gange. Denne fejl vil i bufferen være umulig at skelne fra en bit-fejl i den bit som ikke blev samplet. Du har altså et bitmønster i din buffer UDEN jitter, men med bitfejl. 2. jitteren var ikke stor nok til at forstyre samplingen, der er ingen fejl. Du har altså et bitmønster i din buffer UDEN jitter og uden bitfejl. På det næste led i kæden (fra en buffer til en anden buffer) er der således ikke andet jitter end det der er på selve det led. Jitter akkumuleres altså ikke igennem ledene. Så skal man altså blot gå efter i hvert enkelt led ikke at køre med højere bushastighed end at den jitter der kan opstå ikke er for stor i forhold til en enkelt fase.

JO, lavfrekvent jitter kan godt sive gennem buffer. Læs evt. lidt i jittertråden, der er link til både kilde og måleresultater. Jitter er langt hen af vejen en uoprettelig skade på audiodata, som bør undgås hvis målet er at genskabe den originale lyd.

kyhn skrev: ArneBjarne skrev: Lad os nu for en gangs skyld slå fast at når en bit er indlæst i en buffer så kan den ikke have nogen jitter.. der ikke noget der hedder en 1'er bit med lidt jitter. Når den er i bufferen har den ikke nogen tidsmæssig udstrækning og kan så selvsagt ikke have nogen jitter da det relaterer sig til timing. Hvis der var jitter på signalet der blev indlæst i bufferen så kan der ske 2 ting: 1. jitteren var stor nok til 1 bit blev samplet 2 gange. Denne fejl vil i bufferen være umulig at skelne fra en bit-fejl i den bit som ikke blev samplet. Du har altså et bitmønster i din buffer UDEN jitter, men med bitfejl. 2. jitteren var ikke stor nok til at forstyre samplingen, der er ingen fejl. Du har altså et bitmønster i din buffer UDEN jitter og uden bitfejl. På det næste led i kæden (fra en buffer til en anden buffer) er der således ikke andet jitter end det der er på selve det led. Jitter akkumuleres altså ikke igennem ledene. Så skal man altså blot gå efter i hvert enkelt led ikke at køre med højere bushastighed end at den jitter der kan opstå ikke er for stor i forhold til en enkelt fase. JO, lavfrekvent jitter kan godt sive gennem buffer. Læs evt. lidt i jittertråden, der er link til både kilde og måleresultater. Jitter er langt hen af vejen en uoprettelig skade på audiodata, som bør undgås hvis målet er at genskabe den originale lyd.

Hvor er det så præcis du mener jitter informationen bliver gemt?

Mener du at en bit i bufferen kan kun antage mere end to værdier (0 eller 1)?

Hvis ikke, hvor bliver den så ellers gemt?

 

Den her debat om hvorvidt KS og ASIO fungerer fejlfrit i Windows Vista motiverede mig til at skrive til Larry Osterman, Microsoft udvikler på audio teamet for Windows Vista. Her er hans svar på hvorvidt audio data croppes til 15 bit nogle steder i stakken og hvorvidt KS eller ASIO er deaktiveret i Windows Vista.

Larry Osterman & Elliot Omiya skrev: Yup, that makes sense, thanks for the clarification. -=<EHO>=- -----Original Message----- From: Larry Osterman Sent: Tuesday, January 02, 2007 11:09 AM To: Elliot H Omiya (EHO); 'XO' Subject: RE: (Larry Osterman's WebLog) : Windows Audio You're right (of course) about the float32 - I was confused because float32 can perform lossless functions with 24bits of accuracy (so I always think of there only being 24bits of "resolution" in the float32 value). -----Original Message----- From: Elliot H Omiya (EHO) Sent: Tuesday, January 02, 2007 11:05 AM To: Larry Osterman; 'XO' Subject: RE: (Larry Osterman's WebLog) : Windows Audio No, that is very complete and accurate, with the slight correction that our processing is float32, not 24-bit.  We do not crop the signal anywhere.  As with all modern audio systems that support float32 processing, doing a conversion to int16 involves a dither calculation, but this can in no way be described as "15 bit cropping". ASIO and KS should work once the audio driver works properly on Vista (several companies are working on this prior to consumer launch at the end of this month).  We purposefully did nothing to KS and all KS oriented applications (including ASIO driver written on top of KS) should work fine.  We have been working closely with the audio hardware industry and have seen no across the board problems. -=<EHO>=- -----Original Message----- From: Larry Osterman Sent: Tuesday, January 02, 2007 10:52 AM To: 'XO' Cc: Elliot H Omiya (EHO) Subject: RE: (Larry Osterman's WebLog) : Windows Audio First off, as far as I know, nothing has been done to either ASIO or KS - I'd love to hear where that person got their information. Secondly, as far as cropping goes, we convert all content to 24bit floating point and render it (with no loss of fidelity).  If the user's audio driver doesn't support rendering audio samples in floating point (rendering floating point samples is a Vista logo requirement, so the only devices that don't support this aren't Vista logo compliant), we convert back to fixed point (usually a 16bit format).  When converting from 24bit floating back into 16bit integer, there is a possibility of a data loss (due to the dithering that must be done during the conversion). However, as far as I know, there is no "intentional" cropping of a signal to 15bits. There are a couple of other things to keep in mind.  First off, because we're rendering all audio in floating point format, it means that the quality of our sample rate conversions is several orders of magnitude better than it was on XP - the SRC in XP was measurably poor.  In addition, we fix the output format at (by default) 44.1kHz, which means that CD audio renders through the audio pipeline without conversions (except the int->float->int conversion mentioned above). One other thing to consider - most current audio CDs are rendered so hot that their signals are clipped on the CD - so losing some fidelity isn't going to make a difference to that content. Elliot, anything I missed?

Larry Osterman skrev: One other thing to consider - most current audio CDs are rendered so hot that their signals are clipped on the CD - so losing some fidelity isn't going to make a difference to that content.

Måske ikke lige den rette indstilling.....