Adapter "tystar nätverk" för kräsna ljudentusiaster

Permalänk
Medlem
Skrivet av F.Ultra:

Vad tror du att CIRC på Redbook skivor används till? Hela 25% av informationen på en Redbook skiva är felkorrigerings/detekterings-koder. Hur tror du att spelaren kan använda C1 och C2 till att korrigera fel om den inte kan detektera förekomsten av fel?

Ser man övergripande på det finns det ju olika sorters fel. Ta exempelvis ett felstavat felaktigt påstående. Du kan rätta felstavningen men informationen är ändå fel.

Så om du skriver "jag kna granatera kroekt lsäanig av lujdsikvor" så kan man rätta det till "jag kan garantera korrekt läsning av ljudskivor". Men informationen är fortfarande fel.

Om jag förstått det hela rätt har CIRC att göra med processen att konvertera mellan det datat som faktiskt är skrivet på skivan och det datat det är tänkt att representera. Du kan exempelvis inte skriva en sekvens med färre än 3 nollor på raken till en CD (ytterligare lustig TIL tack vare denna diskussionen)

CIRC kan kanske ses lite som rättstavningen i exemplet ovan, bokstäverna måste bilda ord innan du kan fatta vad datat handlar om.

Dataskivor använder också CIRC men har utöver CIRC andra kontrollmekanismer som även kontrollerar om det som CIRC har rättat faktiskt stämmer med det som skulle skrivits till skivan. Dessa mekanismer saknas eller är bristfälliga för Redbook-skivor.

Skrivet av F.Ultra:

Varför påstår du att jag inte svarar på en fråga som du inte ställt tidigare?

Här är exempel på tidigare gånger som jag ställde frågan specfikt till dig:

Citat:

Det verkar alltså som at omläsning och jämförelser med andra läsningar är det bästa man kan göra.

Vad har du för anledning att tro motsatsen?

Citat:

De som gör rippningsprogram säger allihop att felsäkerheten uppnås genom att läsa flera gånger och jämföra resultaten.

Varifrån tar du stöd för påståendet att det inte fungerar så? En enkel fråga som du borde kunna besvara utan ChatGPT kan jag tycka.

Det du har kommit med hittills är bara påståenden. För att övertyga måste påståendet ha en koppling till något som vi gemensamt accepterar som ett faktum eller bygga på en serie logiska resonemang från det som leder till påståendet.

I mitt fall säger jag exempelvis
1) De som gör rippningsprogram säger att det enda pålitliga sättet att veta om en ripp är korrekt är att göra flera läsningar och jämföra dem med varann. Jag har citerat två av dem.
2) Det ultimata uttrycket för den tanken är AccurateRip-databasen som består av miljontals rips.
3) Det finns flertalet personer som upptäckt att deras rips inte matchar AccurateRip, vilket innebär att fel slinker genom ofta nog att det får ses som relevant.
4) Yellowbook beskrivs specifikt som en standard som utökats för att kunna identifiera och korrigera flera sorters fel vid läsningar som redbook antingen inte kan rätta eller ens upptäcka.

Mitt påstående härleds huvdsakligen från detta, medan ditt påstående är än så länge helt oskiljaktigt från något du har fått för dig och som du vägrar ge upp eftersom du har "vetat" det i evigheter.

Därför undrar jag (för minst tredje gången i den här tråden) - vad bygger du ditt påstående på?

Permalänk
Medlem

Har precis kollat Mad Max: Fury Road och San Andreas på Ultra HD Blu-ray på min Panasonic DMP-UB900 inköpt 160430 (filmerna ingick spelaren) och inser att jag måste köpa framtida filmer på uhd blu-ray, spelaren och filmerna är ju typ sju år gamla och sjukt imponerande jämfört streamat media gällande främst ljudet, bilden är svår att jämföra anekdotiskt. Har precis beställt senaste James Bond filmerna med Daniel Craig på UHD Blu-Ray för att se och höra skillnaden jämfört iTunes versionerna, resultatet kommer självklart vara subjektivt, men för mig mycken intressant information...

Fel århundrade.
Permalänk
Medlem
Skrivet av Sysop:

Har precis kollat Mad Max: Fury Road och San Andreas på Ultra HD Blu-ray på min Panasonic DMP-UB900 inköpt 19160430 (filmerna ingick spelaren) och inser att jag måste köpa framtida filmer på uhd blu-ray, spelaren och filmerna är ju typ sju år gamla och sjukt imponerande jämfört streamat media gällande främst ljudet, bilden är svår att jämföra anekdotiskt. Har precis beställt senaste James Bond filmerna med Daniel Craig på UHD Blu-Ray för att se och höra skillnaden jämfört iTunes versionerna, resultatet kommer självklart vara subjektivt, men för mig mycken intressant information...

Musikbranschen förstör alt, mixar för att passa en gammal transistorradio eller bilstero med en lustig motivering om att alla ska kunna lyssna och att ingen ändå bryr sig om ljudkvalitén.

BIO där vill dom få dit kunder och det måste vara en upplevelse att gå dit då kan dom inte fuska.
Många ljud är inspelade för att låta realistiskt och det kan vara väldig fina micar dom använder typ Earthworks Audio
Earthworks Audio används ofta för att dom fångar ljudet så ofärgat googla på micken
https://www.youtube.com/watch?v=53olXh7um6w&ab_channel=Carter...
https://www.youtube.com/watch?v=w-A3YHDHUrU&ab_channel=ATODru...

Earthworks Audio micar antänds även till ljud för gaming spel

När vi sen kan se filmerna hemma så är det nog oftast en ej förstörd film, bra bild och ljud.
Hembio är en av dom få källorna till bra ljud.

Permalänk
Medlem
Skrivet av Sysop:

Har precis kollat Mad Max: Fury Road och San Andreas på Ultra HD Blu-ray på min Panasonic DMP-UB900 inköpt 19160430 (filmerna ingick spelaren) och inser att jag måste köpa framtida filmer på uhd blu-ray, spelaren och filmerna är ju typ sju år gamla och sjukt imponerande jämfört streamat media gällande främst ljudet, bilden är svår att jämföra anekdotiskt. Har precis beställt senaste James Bond filmerna med Daniel Craig på UHD Blu-Ray för att se och höra skillnaden jämfört iTunes versionerna, resultatet kommer självklart vara subjektivt, men för mig mycken intressant information...

Intressant - jag stör mig själv på legoklossarna man i princip alltid ser i mörka områden från alla streamingtjänster och skulle vilja ha möjligheten att se åtminstone de största favoriterna utan det. 4k bluray verkar ju vara det bästa alternativet som finns just nu.

Men det är lite synd att man måste gå omvägen om blurays.
Jag har "slängt" (donerat/glömt i en låda på vinden) högvis med laserdiscar och dvds, och har nu högvis med 1080-blurays som snart åker samma väg.
Vishet kommer ju (om den kommer) med åldern så så att ta ytterligare ett varv via ett skivformat börjar kännas fel. Jag är säkert på att jag köpt ett antal filmer flera gånger än jag faktistk tittat på dem!

När det mesta av det jag köpt i 1080 från itunes blev gratisuppdaterat till 4k skippade jag UHD-bluray, men som du säger är det ju märkbar skillnad.
Det har gått rätt lång tid nu men hoppet lever att Apple gör om manövern och erbjuder 4K med högre bitrate som gratis uppgradering också - eller något.

Det verkar ju onekligen dröja dock, vi kan ha fallit i den fällan som slukar allt annat coolt för oss nördar, nämligen att den stora massan inte bryr sig så det händer inget. Och då är UHD Bluray det bästa vi får i överskådlig tid.

Lustigt att detta blev tråden för alltmöjligt men jag klagar inte!

Permalänk
Medlem
Skrivet av 0cool:

Ser man övergripande på det finns det ju olika sorters fel. Ta exempelvis ett felstavat felaktigt påstående. Du kan rätta felstavningen men informationen är ändå fel.

Så om du skriver "jag kna granatera kroekt lsäanig av lujdsikvor" så kan man rätta det till "jag kan garantera korrekt läsning av ljudskivor". Men informationen är fortfarande fel.

Om jag förstått det hela rätt har CIRC att göra med processen att konvertera mellan det datat som faktiskt är skrivet på skivan och det datat det är tänkt att representera. Du kan exempelvis inte skriva en sekvens med färre än 3 nollor på raken till en CD (ytterligare lustig TIL tack vare denna diskussionen)

CIRC kan kanske ses lite som rättstavningen i exemplet ovan, bokstäverna måste bilda ord innan du kan fatta vad datat handlar om.

Dataskivor använder också CIRC men har utöver CIRC andra kontrollmekanismer som även kontrollerar om det som CIRC har rättat faktiskt stämmer med det som skulle skrivits till skivan. Dessa mekanismer saknas eller är bristfälliga för Redbook-skivor.

Här är exempel på tidigare gånger som jag ställde frågan specfikt till dig:

Det du har kommit med hittills är bara påståenden. För att övertyga måste påståendet ha en koppling till något som vi gemensamt accepterar som ett faktum eller bygga på en serie logiska resonemang från det som leder till påståendet.

I mitt fall säger jag exempelvis
1) De som gör rippningsprogram säger att det enda pålitliga sättet att veta om en ripp är korrekt är att göra flera läsningar och jämföra dem med varann. Jag har citerat två av dem.
2) Det ultimata uttrycket för den tanken är AccurateRip-databasen som består av miljontals rips.
3) Det finns flertalet personer som upptäckt att deras rips inte matchar AccurateRip, vilket innebär att fel slinker genom ofta nog att det får ses som relevant.
4) Yellowbook beskrivs specifikt som en standard som utökats för att kunna identifiera och korrigera flera sorters fel vid läsningar som redbook antingen inte kan rätta eller ens upptäcka.

Mitt påstående härleds huvdsakligen från detta, medan ditt påstående är än så länge helt oskiljaktigt från något du har fått för dig och som du vägrar ge upp eftersom du har "vetat" det i evigheter.

Därför undrar jag (för minst tredje gången i den här tråden) - vad bygger du ditt påstående på?

Och jag har svarat på dessa frågor om och om igen, du gillar bara inte svaret eftersom det bryter mot din bias om Redbook.

1) Ja som jag nu skrivet många många ggr så beror det på att många cd-läsare inte rapporterar vidare antalet C1/C2 korrigeringar vilket gör att en rippare inte vet om ifall den interpolerad info från spelaren. Finns dock återigen inget i standarden som säger att spelaren måste göra så här utan spelarna gör så för att det är det mest användarvänliga. Så om du vill göra en poäng av att en spelare som inte rapporterar C1/C2 fel inte är designad för 100% korrekt bit-återgivning så kommer du inte att få några protester om det, men nu var det inte vad det handlade om.

2) Vilket beror dels på 1)

3) Vilket kan beror på 1) alt på lead-in och/eller lead-out.

4) Vilket ingen har motsagt heller, tvärtom har jag skrivit det flera ggr vid det här laget. Ja Yellowbook har utökade felkorrigering och utökad feldetektering mot Redbook. Men ska vi följa den logiken så kan du inte längre anse att Yellowbook är till för 100% bitåtergivning då vi nu har DVD-ROM, och sedan BR och sedan än mer avancerade kodningar för moderna SSD:s eftersom varje nytt sådant medium har fått än mer utökade feldetektering och felkorrigering. Då skulle t.ex jag kunna påstå att jag som kör BTRFS har ett filsystem som stödjer 100% bitåtergivning medan du (och om inte du så många andra) som kör NTFS enbart har ett filsystem som klarar att återskapa informationen hörbart.

Och nej du har fel ang CIRC, det finns inte till för att konvertera mellan det som är skrivet på skivan mot det som det är tänkt att representera. Det är till för att korrigera de ev fel som kan uppstå om lasern råkar läsa fel pga t.ex vibrationer eller för att skivan har smuts eller repor. Du kan se det som en mer avancerad form av den paritetsdata som man använder i RAID-2 och uppåt.

Det du tänker på med "inte färre än 3 nollor på raken" har inte med CIRC att göra utan med EFM (Eight-to-Fourteen Modulation) som är hur själva bitarna är enkodade på skivan. Dvs en byte om 01011101 enkodas på skivan som 00001000010100001010100000000100100010, CIRC i form av C1 och C2 sker innan det steget. Sen bara för att vara än mer komplicerad så appliceras ESM RLL ovanpå detta så att det till slut blir 00000000100000000001000100000010010000100000010000000000001000100001000000000010, så även utan C1 och C2 så tar varje byte 5 bytes att lagras där både EFM och ESM lägger på paritetsbitar som CIRC-kretsen sen använder för att detektera och korrigera en del fel innan den ens börjar med C1 och C2.

I princip har du först 24 bytes av PCM som sedan följs av 4 bytes som är paritetsdatan (i verkligheten lagras datan interleavat, därav att det kallas CIRC, så det är ju inte 24+4 utan det är dels data från båda kanalerna, så 48+8, och dels lagras de blandat och inte linjärt i förhoppningen om att en repa ska påverka färre antal bitar i följd av samma data sas). Dessa 4 paritetsbytes räknas fram genom att man omvandlar de 24 data-bytesen till ett polynom, sedan delar man det polynomet med sin generator (ett polynom som man bestämt i förväg) och heltalskvoten blir paritetsdatan.

Så när du läser av informationen så gör du samma beräkning och om du då får en annan heltalskvot än vad du läste från skivan så har du detekterat ett fel, du kan sedan mha de 24+4 som du läst och de 4 som du precis beräknat räkna baklänges vad de 24 skulle ha blivit och så länge som antalet fel är inom en viss gräns så kan du till 100% återskapa dessa 24 bytes.

Yellowbook utökade detta från 24+4 till 28+8 och för Yellowbook mode 1 så lade man även till 4-bytes crc-32 per 2352-bytes sektor. CRC har ju då nackdelen att den inte kan göra felkorrigering som CIRC, dock har den utökad möjlighet till feldetektering mot CIRC (dock och det är ju det som jag så envist upprepar gång på gång är att även CIRC har ju feldetektering).

CRC är ju dock inte magi heller så det kommer att kunna generas fel som kan slinka igenom även den så Yellowbook är ju på inget sätt 100% skyddat mot silent corruption. Hårddiskar och framförallt moderna SSDs som ofta kör med LDPC har ju en felkorringering och feldetekteringsförmåga som vida överstiger den hos Yellowbook och trotts det så behövs det filsystem som ZFS och BTRFS för att flytta gränsen för silent corruption.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av F.Ultra:

Och jag har svarat på dessa frågor om och om igen, du gillar bara inte svaret eftersom det bryter mot din bias om Redbook.

Dina svar är bara påståenden om CD-skivor, min fråga är var du tar påståendena från. Det har du aldrig svarat på, inte denna gången heller.
Ser du dina påståenden som axiom eller vad är problemet? Varför vill du aldrig svara på frågan?

Skrivet av F.Ultra:

1) Ja som jag nu skrivet många många ggr så beror det på att många cd-läsare inte rapporterar vidare antalet C1/C2 korrigeringar vilket gör att en rippare inte vet om ifall den interpolerad info från spelaren.

De som gör en av de erkänt bästa rippningsprorammen säger att det inte spelar någon roll hur bra spelare du än har:

Citat:

C2 Error Pointers

Each drive chipset implements C2 pointers with differing levels of quality, even the best implementation can still let through 3% or more errors through. Having C2 helps, but should not be relied upon alone.

Intressant nog säger din Overlord att C2 inte ingår i RedBook-standarden vilket ju förklarar varför det blir fel även om spelaren i teorin skulle kunna läsa C2. Ljudskivor som följer RB har inte C2-information i sitt data.

Citat:

do audio cds contain c2 error codes
Audio CDs (Red Book standard) do not contain C2 error codes.

C2 error codes are a feature of the Yellow Book standard for data CDs, and are used to provide additional error correction beyond what is provided by the C1 error correction codes. However, in the Red Book standard for audio CDs, only C1 error correction codes are used.

Därför tycker jag det är helt rätt att säga att RB inte är designat för att vara bitperfekt medan YB faktiskt är designat för att vara bitperfekt.

Ett sätt att kolla en teori är ju att se om den kan förutse saker i verkligheten. Om RB inte är designat för att vara bitperfekt så borde vi kunna observera exempelvis:

1) Det borde vara så vanligt att personer får olika resultat när de läser samma redbookskiva att det finns flertalet exempel på detta "in the wild". Japp, det vet vi.
2) Det borde ha tagits fram en separat standard som används för data där bitperfektion är viktigt - japp, det gör det.

Om man istället tänker sig att det finns läsare som kan läsa ljudskivor perfekt så borde det innebära andra observationer.

1) De som gör rippningsmjukvara borde nämna dessa spelare som felsäkra i alla lägen. Nix, något sådant har jag aldrig sett.
2) Man borde kunna använda redbook-skivor som lagrinsgsmedium för generellt data bara man har rätt sorts spelare, varför en ny standard för formatet inte hade behövts. Nix, man lagrar inte data i redbookformat.

Du tycker säkert jag har fel fortfarande men du kanske ändå kan se hur även en intelligent person kan lockas att tro det jag tror utifrån resonemanget?

Det är svårare att övertygas av någon som i princip bara säger "jag har rätt eftersom jag sagt det flera gånger".

Permalänk
Hedersmedlem
Skrivet av 0cool:

Intressant nog säger din Overlord att C2 inte ingår i RedBook-standarden vilket ju förklarar varför det blir fel även om spelaren i teorin skulle kunna läsa C2. Ljudskivor som följer RB har inte C2-information i sitt data.

Därför tycker jag det är helt rätt att säga att RB inte är designat för att vara bitperfekt medan YB faktiskt är designat för att vara bitperfekt.

Fast där har isåfall ChatGPT fel.

https://www.blantonemusic.com/redbook-standard

Citat:

C2 Errors

C2 Errors are a "bit" more serious, and can render a disc unplayable. Some CD players can correct these upon playback, but not with all players and not with all discs. C2 errors generally indicate poor quality media was used in the write/burn process. Master discs produced here contain absolutely no C2 errors. [...]

CU Errors

CU Errors are the most serious and without exception cause a disc to be unplayable/unusable. These errors occur after a disc player has tried to correct C2 errors and has failed in doing so. This generally means that some data has been lost on the disc and cannot be recovered by the playback mechanism

Min fetstil.

Mer formell källa är Red Book-standarden, sida 34 som också nämner att C1 och C2 används.

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
Mobil: Moto G200

Permalänk
Medlem
Skrivet av 0cool:

Dina svar är bara påståenden om CD-skivor, min fråga är var du tar påståendena från. Det har du aldrig svarat på, inte denna gången heller.
Ser du dina påståenden som axiom eller vad är problemet? Varför vill du aldrig svara på frågan?

Så du menar att jag måste förklara för dig att felkorrigeringskoder ala Reed-Solomon fungerar som om det vore helt okänd teknik? Eller att man måste kunna detektera fel för att även kunna korrigera fel? Vad är det egentligen som du anser att jag inte har förklarat och som du har så svårt att förstå?

Skrivet av 0cool:

De som gör en av de erkänt bästa rippningsprorammen säger att det inte spelar någon roll hur bra spelare du än har:

Sån tur då att jag hela tiden har förklarat att jag pratar om specen och inte hur den implementerats i praktiken.

Skrivet av 0cool:

Intressant nog säger din Overlord att C2 inte ingår i RedBook-standarden vilket ju förklarar varför det blir fel även om spelaren i teorin skulle kunna läsa C2. Ljudskivor som följer RB har inte C2-information i sitt data.

Nej det där stämmer inte, sen kanske det stämmer att det finns spelare där ute som inte gör detta korrekt men det förändrar inget i sak. Det finns gott som kontrollchip för både cd, floppy, hdd och ssd som gör liknande fel från fall till fall så det saknar relevans eftersom du anser att YB är 100% korrekt, om du ändrar din åsikt till att inget format är 100% perfekt så kommer du mer över till min sida.

Skrivet av 0cool:

Ett sätt att kolla en teori är ju att se om den kan förutse saker i verkligheten. Om RB inte är designat för att vara bitperfekt så borde vi kunna observera exempelvis:

1) Det borde vara så vanligt att personer får olika resultat när de läser samma redbookskiva att det finns flertalet exempel på detta "in the wild". Japp, det vet vi.
2) Det borde ha tagits fram en separat standard som används för data där bitperfektion är viktigt - japp, det gör det.

1) finns flertal exempel in the wild på personer som får olika resultat när de läser av data från en hdd eller ssd också, så det bevisar inget mer än att det finns dåliga implemenationer där ute eller att det finns folk med för skadade skivor där ute. Hade själv en 1541-klon när jag var tonåring som inte alltid gav tillbaka samma data vid läsningar, var till slut tvungen att ta av chassiet och lär mig hålla ett specifikt tryck med fingrarna på läshuvudet för att den skulle bli med konsekvent i vad den läste av.

2) RB passar inte till att lagra datamedia pga att RB inte delar in skivan i rena sektorer (därför som det kan bli strul med t.ex lead-in och lead-out) så själva strukturen passar väldigt dåligt med vad en dator förväntar sig. Nu har vi ju inte tillgång till de interna diskussionerna hos Sony/Philips när de skapade YB men att strukturen är illa passande är allmänt känt. Att man sedan passade på att utöka felkorrigeringen och feldetekteringen ser jag mindre som ett måste från deras sida och mer att de säkert tänkte att 700MB är så enormt mycket data för ett lagringsmedium ändå så om vi lägger på extra paritetsbitar och checksummor så får vi ett format som har både stor lagringskapacitet OCH ett som är extremt driftssäkert så att vi bättre kan sälja in det som ett alternativ till konkurrerande format. Helt min egen teori förstås pga vad jag skrev innan.

Skrivet av 0cool:

Om man istället tänker sig att det finns läsare som kan läsa ljudskivor perfekt så borde det innebära andra observationer.

1) De som gör rippningsmjukvara borde nämna dessa spelare som felsäkra i alla lägen. Nix, något sådant har jag aldrig sett.
2) Man borde kunna använda redbook-skivor som lagrinsgsmedium för generellt data bara man har rätt sorts spelare, varför en ny standard för formatet inte hade behövts. Nix, man lagrar inte data i redbookformat.

1) finns inget lagringsmedium i världen som är felsäkra i alla lägen, så det är felaktig premiss från din sida att ens ta upp.
2) klart att du kan använda Redbook som lagringsmedium för generell data, det skulle bara vara extremt komplext då strukturen inte är designad för arbiträr data eftersom det inte finns rena sektorer eller spår, Skulle också helt sakna existensberättigande eftersom det ju nu finns en Yellowbook. Det sagt så fanns det t.ex när jag var tonåring system för att lagra generell data på VHS spelare och om du tycker att Redbook är dåligt för att lagra data på så kan du ju tänka dig exakt hur bra VHS är.

Skrivet av 0cool:

Du tycker säkert jag har fel fortfarande men du kanske ändå kan se hur även en intelligent person kan lockas att tro det jag tror utifrån resonemanget?

Det är svårare att övertygas av någon som i princip bara säger "jag har rätt eftersom jag sagt det flera gånger".

Ännu svårare när du inte anger vad det är som du vill att jag ska förklara när jag anser att olika grad av felkorrigering och feldetektering inte ger en skillnad i om ett format är designat för "hörbart perfekta resultat," vs "bit-perfekta resultat". Dvs det hela här handlar ju inte hur Redbook eller Yellowbook fungerar rent tekniskt (vill du veta det får du punga ut några tusen spänn per spec från ISO) utan din ide om att det finns en gräns någonstans i hur mycket feldetektering och felkorrigering som ett medium har skulle på något vis ge denna skillnad.

Vilket också gör att du konstant har duckat mina frågor om varför inte t.ex floppies eller NTFS för delen tillhör den första kategorin när båda har lägre halt av båda än vad Redbook har. Eller hur du konstant duckar frågan om att om nu det faktum att Yellowbook är bättre än Redbook, varför då inte format/specar som är bättre än Yellowbook gör samma sak med Yellowbook i din värld som Yellowbook gör med Redbook.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av Thomas:

Fast där har isåfall ChatGPT fel.

https://www.blantonemusic.com/redbook-standard

Min fetstil.

Mer formell källa är Red Book-standarden, sida 34 som också nämner att C1 och C2 används.

Tja rent tekniskt är det ju korrekt. Jag menar klart det kan finnas spelare där ute som helt ignorerar C2 precis som det fanns diskkontrollers till PC som helt ignorerade CRC från floppy diskar trotts att formatet för floppies har en CRC-16 per block om 512-bytes.

T.ex SUN stötte ju på flera exempel med SCSI kontrollers och nätverkskort som under vissa förhållanden stoppade in slumpvis bitförändringar i datan de skulle leverera vilket var anledningen till att de skapade ZFS.

Precis som det finns kablar märkta för att stödja HDML2.1 men som defactor inte gör det, undermåliga produkter har alltid funnits.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av Thomas:

Fast där har isåfall ChatGPT fel.

ChatGPT har ingen aning om något och är helt värdelös som faktakälla, bara så det inte råder något missförstånd om vad jag tror om det. Den är dock användbar som hjälpmedel att komma fram till rätt frågor att ställa mot andra källor.

Skrivet av Thomas:

Mer formell källa är Red Book-standarden, sida 34 som också nämner att C1 och C2 används.

Grymt jobbat att hitta den formella standarden, tack och bock! Jag hittade bara ställen som skulle ha över tusen spänn för den

Det sagt, jag tror inte att vare sig Blantone Music eller sidan 34 i standarden säger något som är ett motargument för påståendet från ChatGPT.

Blantone pratar om skrivning av cd-skivor, och säger att deras masters inte har C2-fel. Det verkar alltså syfta på något annat än huruvida de inkluderar den informationen som behövs för att kunna korrigera C2-fel vid läsning.

Standarden nämner på sidan 34 att CIRC består av två separat enkodade dataströmmar som den benämner C1 och C2 och vilken storlek på data vs paritet som dessa har, men det är alltså själva CIRC-mekanismen de beskriver där och det är inte en referens till C1 och C2-felkoder.

Nu som vi har standarden kan vi ju lusläsa den för att hitta det exakta svaret förstås, det kanske döljer sig någon annanstans än på sidan 34. Någon frivillig?

Permalänk
Medlem
Skrivet av 0cool:

ChatGPT har ingen aning om något och är helt värdelös som faktakälla, bara så det inte råder något missförstånd om vad jag tror om det. Den är dock användbar som hjälpmedel att komma fram till rätt frågor att ställa mot andra källor.

Grymt jobbat att hitta den formella standarden, tack och bock! Jag hittade bara ställen som skulle ha över tusen spänn för den

Det sagt, jag tror inte att vare sig Blantone Music eller sidan 34 i standarden säger något som är ett motargument för påståendet från ChatGPT.

Blantone pratar om skrivning av cd-skivor, och säger att deras masters inte har C2-fel. Det verkar alltså syfta på något annat än huruvida de inkluderar den informationen som behövs för att kunna korrigera C2-fel vid läsning.

Standarden nämner på sidan 34 att CIRC består av två separat enkodade dataströmmar som den benämner C1 och C2 och vilken storlek på data vs paritet som dessa har, men det är alltså själva CIRC-mekanismen de beskriver där och det är inte en referens till C1 och C2-felkoder.

Nu som vi har standarden kan vi ju lusläsa den för att hitta det exakta svaret förstås, det kanske döljer sig någon annanstans än på sidan 34. Någon frivillig?

Och vad är det för exakt svar som du är ute efter? Som du själv kan se på sidan 34 så finns det två nivåer av felkorrigerings och feldetekteringskoder inom CIRC på Redbook, benämt C1 och C2. På Yellowbook så benämns de C1 och C3. Utöver detta så har du paritetsbitar från ESM och EFM.

Är det helt omöjligt för dig att tänka dig att man skulle kunna skapa en spelare som vid antal C1- och C2-fel som överstiger specen för vad de kan korrigera till 100% bara stoppar och ger en felkod?

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av F.Ultra:

Så du menar att jag måste förklara för dig att felkorrigeringskoder ala Reed-Solomon fungerar

Nej inte alls. Baserat på dina tidigare inlägg tror jag vi upptäckte Reed-Solomon samtidigt så jag tror vi är på samma banhalva vad gäller den. Du kanske förstår den bättre för allldel, jag har inte implementerat den i egen kod, det kanske du har. Fasen om det slutar med att en av oss faktiskt gör det!

Jag kanske var otydlig, men jag vill alltså att du skall förklara varifrån du tar dina påståenden. Jag vill inte veta vad du tycker om dina egna påståenden eller detaljer i dina egna påståenden, jag vill veta vilken pålitlig faktakälla du tar det från.

Inget annat.

Skrivet av F.Ultra:

Sån tur då att jag hela tiden har förklarat att jag pratar om specen och inte hur den implementerats i praktiken.

Nu har vi hjälp av @Thomas som faktiskt hittade specen. Och den säger ju att jag har rätt!

Jag sade:

Skrivet av 0cool:

felkorrigeringen på ljudskivor är alltså designad för att ge hörbart perfekta resultat, inte bit-perfekta resultat.

Standarden säger på sidan 28:

Citat:

errors in the h.f. signal due to local defects shall not induce audible effects for any error- correcting decoding strategy

När standarden säger att felkorrigeringen är godkänd så länge den inte ger hörbara effekter så är det väl rättvist att säga att den är designad för att ge hörbart perfekta resultat, men inte nödvändigtvis bitperfekta resultat?

Skrivet av F.Ultra:

du anser att YB är 100% korrekt

Jueezus nej, jag anser verligen inte att YB är 100% korrekt. Jag anser att inget är perfekt. Jag har kört ZFS kontinuerlig i över 10 år (började under Solaris), och kör Storage Spaces med paritet i windows just för att inget är perfekt.

I pedantisk mening kan jag absolut hålla med dig att man kan se det som en kontinuerlig skala, men problemet med det resonemanget är ju att du då postulerar att allt är designat för att vara bitperfekt, oavsett hur kass felkontrollen är. Allting är ju bara på en skala sämre.

Jag tycker det avgörande är just att redbook uttrycker att felkorrigeringen siktar mot hörbart perfekt. Nu visste jag förstår inte att det faktiskt stod ordagrant innan @Thomas hittade standarden men det gick ju att härleda baserat på det vi observerat i verkligheten.

Det är alltså noterat i specen att bitperfektion inte är nödvändig så länge felet inte hörs, och det är i min mening en avgörande skillnad.

Jag tror detta är anledningen till att man kan få lyckade rips med varierande checksumma, dvs att det beror på brister i standarden i sig inte i enskilda läsare eller firmware.

Om du inte tycker det är helt rätt kanske vi kan mötas i att det inte är helt fel och "agree to disagree" om resten, vad sägs?

Permalänk
Medlem

Bara för skoj skull så tog jag samma skiva som jag tidigare enbart rippat spår 1 från och rippade nu hela skivan. Dock gjorde jag det både med "cdparanoia -Z 1-12 no" och "cdparanoia 1-12 yes". För de av ser om inte vet det så stänger -Z av alla former av felkorrigering och omläsningar mm som cdparanoia annars gör, dvs med -Z så gör den en ren dump av den data som cd-spelaren genererar. "yes" och "no" är sedan bara filnamnen för ripparna/dumparna som den genererar.

I båda fallen så skapades det filer med längden 788M och en stark checksumma på båda gav att de är bitidentiska:

Citat:

fultra@Sineya:~/test3$ cdparanoia -vsQ
cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2
Using paranoia library version: 10.2
Checking /dev/cdrom for cdrom...
Testing /dev/cdrom for SCSI/MMC interface
SG_IO device: /dev/sr0

CDROM model sensed sensed: TSSTcorp CDDVDW SH-S223B SB02

Checking for SCSI emulation...
Drive is ATAPI (using SG_IO host adaptor emulation)

Checking for MMC style command set...
Drive is MMC style
DMA scatter/gather table entries: 1
table entry size: 131072 bytes
maximum theoretical transfer: 55 sectors
Setting default read size to 27 sectors (63504 bytes).

Verifying CDDA command set...
Expected command set reads OK.

Attempting to set cdrom to full speed...
drive returned OK.

Table of contents (audio tracks only):
track length begin copy pre ch
===========================================================
1. 27226 [06:03.01] 0 [00:00.00] no no 2
2. 24889 [05:31.64] 27226 [06:03.01] no no 2
3. 32788 [07:17.13] 52115 [11:34.65] no no 2
4. 25359 [05:38.09] 84903 [18:52.03] no no 2
5. 27138 [06:01.63] 110262 [24:30.12] no no 2
6. 41299 [09:10.49] 137400 [30:32.00] no no 2
7. 32280 [07:10.30] 178699 [39:42.49] no no 2
8. 33101 [07:21.26] 210979 [46:53.04] no no 2
9. 31885 [07:05.10] 244080 [54:14.30] no no 2
10. 28524 [06:20.24] 275965 [61:19.40] no no 2
11. 21330 [04:44.30] 304489 [67:39.64] no no 2
12. 25066 [05:34.16] 325819 [72:24.19] no no 2
TOTAL 350885 [77:58.35] (audio only)

fultra@Sineya:~/test3$ cdparanoia -Z 1-12 no
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector 0 (track 1 [0:00.00])
to sector 350884 (track 12 [5:34.15])

outputting to no

(== PROGRESS == [ | 350884 00 ] == :^D * ==)

Done.

fultra@Sineya:~/test3$ cdparanoia 1-12 yes
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector 0 (track 1 [0:00.00])
to sector 350884 (track 12 [5:34.15])

outputting to yes

(== PROGRESS == [ | 350884 00 ] == :^D * ==)

Done.

fultra@Sineya:~/test3$ ls -l
totalt 1611896
-rw-rw-r-- 1 fultra fultra 15891 apr 1 22:46 cdparanoia.log
-rw-rw-r-- 1 fultra fultra 825281564 apr 1 22:49 no
-rw-rw-r-- 1 fultra fultra 825281564 apr 1 22:57 yes
fultra@Sineya:~/test3$ sha512sum yes no
7099d4d6153f1066e6bc1e85ced837718da24a5bbe15f1e981641467dab3d1605fd1426a2d93c7dcc08973d0a27ae72fcdab16d9c7a2b3464eb99f3959573ef2 yes
7099d4d6153f1066e6bc1e85ced837718da24a5bbe15f1e981641467dab3d1605fd1426a2d93c7dcc08973d0a27ae72fcdab16d9c7a2b3464eb99f3959573ef2 no

Bevisar naturligtvis ingenting mer än att min spelare med just min skiva har förmågan att producera en bitidentisk kopia både när den läses av i realtid och när man läser om varje datablock flera ggr för att se om man får olika svar.

MEN det visar ju att förmågan att skapa en bitidentisk kopia finns, filerna ovan är ju inte ljudmässigt identiska, de är 100% bitidentiska.

Kommer samma sak att hända med en skiva som har så pass mycket repor och/eller smuts att antalet fel överstiger det som EFM+ESM+CIRC kan korrigera för?

Naturligtvis inte, men det är ju inte unikt för Redbook skivor utan gäller ju för samtliga former av felkorrigering och feldetektering, t.ex Yellowbook har ju en CRC-32 per 2366 bytes eller vad det nu är, då en CRC-32 är 4-bytes lång så borde samtliga här inse att det naturligtvis kan förekomma fel på dessa 2366 bytes som kommer att generera samma CRC-32 som originalet. Det handlar ju enbart om sannolikheten för att det ska kunna ske spontant med de typer av bitfel som man kan få i det medium där checksumman används.

MEN det är ju inte heller den frågeställning som det handlar om här, utan den är ju om cd-spelaren måste svara med ett interpolerat/gissat svar när det blir för mycket fel eller om den skulle kunna generera en felkod istället och därmed låta användare veta att spåret/skivan är för skadad för att den ska kunna ge ett bitidentiskt svar.

Här borde man med ren logik inse att spelaren måste ju veta om utifall den ska göra en interpolering/gissning för annars kan den ju inte göra det, och vet den om när den skall göra en sådan interpolering/gissning så kan den naturligtvis också välja att istället ge en felkod och stanna där.

Att sedan en cd-spelare som spelar upp en musikskiva väljer att interpolera (eller göra ett kort hopp i spåret) istället för att helt sonika stänga av sig för att det är mer användarvänligt borde ju inte heller vara svårt att inse?

Vad exakt är det som är oklart med detta?

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av F.Ultra:

Som du själv kan se på sidan 34 så finns det två nivåer av felkorrigerings och feldetekteringskoder inom CIRC på Redbook

Vad jag kan se beskriver sidan 34 bara att CIRC består av två separata Reed-solomonsekvenser, där den ena är encodad med 28 databitar och 4 paritetsbitar, och den andra med 24 databitar och 4 paritetsbitar.

Att dessa benämns C1 och C2 verkar mer vara ett sammanträffande, eftersom båda dessa alltid måste läsas för att kunna dekoda grunddatat så är det ju inte på något sätt valfritt att läsa det som i standarden benämns "C2".

Då kan det ju inte handla om samma "C2 errors" som vissa läsare stödjer och andra inte stödjer, spekulerar jag.

Eller missar jag något här? (Obs, jag har inte hunnit läsa hela standarden!)

Permalänk
Medlem
Skrivet av 0cool:

Nej inte alls. Baserat på dina tidigare inlägg tror jag vi upptäckte Reed-Solomon samtidigt så jag tror vi är på samma banhalva vad gäller den. Du kanske förstår den bättre för allldel, jag har inte implementerat den i egen kod, det kanske du har. Fasen om det slutar med att en av oss faktiskt gör det!

Nej jag har jobbat med Reed-Solomon sedan 1997 när jag jobbade med digital överföring via Satelliter. Så jag har implementerat det i kod många ggr om (och även andra typer av liknande enkodings).

Skrivet av 0cool:

Jag kanske var otydlig, men jag vill alltså att du skall förklara varifrån du tar dina påståenden. Jag vill inte veta vad du tycker om dina egna påståenden eller detaljer i dina egna påståenden, jag vill veta vilken pålitlig faktakälla du tar det från.

Ok, bara jag som blev lite förvånad för att Redbook har C1+C2 samt EFM och EFS osv inte var allmängods. Och även att Reed-Solomon liknande enkodings används till både felkorrigering och feldetektering (dvs att det var ifrågasatt).

Skrivet av 0cool:

Nu har vi hjälp av @Thomas som faktiskt hittade specen. Och den säger ju att jag har rätt!

Jag sade:
Standarden säger på sidan 28:

När standarden säger att felkorrigeringen är godkänd så länge den inte ger hörbara effekter så är det väl rättvist att säga att den är designad för att ge hörbart perfekta resultat, men inte nödvändigtvis bitperfekta resultat?

Fast det är inte vad ditt citat påstår. Vad den säger är att högfrekvenssignalen från laserdioden inte får påverka ljudsignalen vid felkorrigering av burstfel (dvs fel som påverkar flera bitar på rad). Det är inte samma sak som "felkorrigering garanterar inte bitperfekt resultat". Det citatet säger ingenting öht om när felkorrigeringen är godkänd eller ej utan bara att implementationen inte får gå in och manipulera ljudisgnalen vid burstfel.

Skrivet av 0cool:

I pedantisk mening kan jag absolut hålla med dig att man kan se det som en kontinuerlig skala, men problemet med det resonemanget är ju att du då postulerar att allt är designat för att vara bitperfekt, oavsett hur kass felkontrollen är. Allting är ju bara på en skala sämre.

Verkligen inte, för jag anser att hela premissen med att ett format kan garantera 100% bitperfekt återgivning under alla förhållande är felaktig. Det som jag däremot hela tiden reagerar mot är att påstå att Redbook inte är designat för att vara så bitperfekt som den kan, för det är den. Hade deras plan varit att vara hörbart perfekt istället så hade de implementerat enkodings likt mp3 istället så att felkorrigeringen hade jobbat på ljudnivå istället för på bitnivå.

Dvs bara förekomesten av Reed-Solomon gör det till korrigering på bitnivå. Reed-Solomon har ingen koll på hur det låter.

Skrivet av 0cool:

Det är alltså noterat i specen att bitperfektion inte är nödvändig så länge felet inte hörs, och det är i min mening en avgörande skillnad.

Fast nu står det ju inte så i specen.

Skrivet av 0cool:

Jag tror detta är anledningen till att man kan få lyckade rips med varierande checksumma, dvs att det beror på brister i standarden i sig inte i enskilda läsare eller firmware.

Ja och nej, klart att det finns brister i specen. T.ex hade det varit mycket bättre om man hade hårt specat offset och lead-in samt lead-out, då hade inte olika spelare tillåtits att ha olika värden för detta och antalet spelare som generera olika rippar hade minskat rejält. Om man korrigerar för dessa dock (och den korrigeringen handlar inte om att ändra på bitdatan av låten) så får man (påstår jag iaf, och mina egna tester pekar på att det är korrekt) så minskar antalet skillnader rejält.

Det till trotts så finns det ju sen skivor där man ignorerat ifrån Redbook helt, vilket visar att det kvittar ju om specen är bra om nu ingen följer den, med t.ex korkade försök till kopieringsskydd där man medvetet skapat fel i C1+C2 datan i hopp om att en rippare som är noggrann kommer att skapa en felaktig kopia. Och att sådana skivor ger olika resultat vid omläsningar är ju inte formatets fel utan den specifika skivans fel.

Och finns det bättre och sämre skivor så finns det bättre och sämre spelare/firmwares. Och som jag nämnt tidigare så har ms-dos floppies en crc-16 per 512-bytes block men det fanns diskkontroller chips till tidiga modeller av PC:n som helt ignorerade att läsa av den, så där har vi ett till exempel där det inte är fel på formatet utan på implementeringen.

Skrivet av 0cool:

Om du inte tycker det är helt rätt kanske vi kan mötas i att det inte är helt fel och "agree to disagree" om resten, vad sägs?

inga problem. Finns ju ingen anledning att spendera resten av livet i en diskussion om ett format som knapps ens används längre

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av 0cool:

Vad jag kan se beskriver sidan 34 bara att CIRC består av två separata Reed-solomonsekvenser, där den ena är encodad med 28 databitar och 4 paritetsbitar, och den andra med 24 databitar och 4 paritetsbitar.

Att dessa benämns C1 och C2 verkar mer vara ett sammanträffande, eftersom båda dessa alltid måste läsas för att kunna dekoda grunddatat så är det ju inte på något sätt valfritt att läsa det som i standarden benämns "C2".

Då kan det ju inte handla om samma "C2 errors" som vissa läsare stödjer och andra inte stödjer, spekulerar jag.

Eller missar jag något här? (Obs, jag har inte hunnit läsa hela standarden!)

Var kanske för otydlig här. Vad jag menar är att det finns spelare som rapporterar vidare antalet C1 och C2 fel som de har mätt och korrigerat för. Om en rippare kan få den informationen från spelaren så vet den om inom vilken gräns som spelaren har korrigerat för fel och kan då göra en kvalificerad bedömning om den ska be spelaren att läsa om blocket eller inte.

För spelare som inte rapporterar denna data (eller som rapporterar den felaktigt) så vet ju inte ripparen om utifall spelaren har läst av ett block som har ett antal fel som överstiger maxgränsen för vad CIRC kan korrigera för eller om den har läst av ett block 100% perfekt så därför har ripparen inget annat val än att läsa om samma block flera ggr medan samma rippare med en bättre spelare bara behöver göra det på problematiska block och därmed bli mycket mycket snabbare.

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av F.Ultra:

Verkligen inte, för jag anser att hela premissen med att ett format kan garantera 100% bitperfekt återgivning under alla förhållande är felaktig.

Jag håller i så fall med men vill understryka att det inte var mitt påstående. Mitt argument handlar inte om att något format verkligen är matematiskt perfekt, utan att redbook specifikt tillåter att resultatet inte är perfekt.

Skrivet av F.Ultra:

inga problem. Finns ju ingen anledning att spendera resten av livet i en diskussion om ett format som knapps ens används längre

Så sant.

Permalänk
Medlem
Skrivet av F.Ultra:
Skrivet av 0cool:

Hur bra eller dåligt funkar dagens program?
Jag har aldrig rippat ni verkar kunna och därför frågar jag er .

Förslag på rätt program och lämplig hårdvara motages tacksamt.
Har funderat på att rippa mina cd men det har aldrig blivit av.

Jag har inte orkat läsa alt ni har skrivit, om det redan är nämnt kan ni sammanfatta.

Permalänk
Medlem
Skrivet av Teknik:

Hur bra eller dåligt funkar dagens program?
Jag har aldrig rippat ni verkar kunna och därför frågar jag er .

Förslag på rätt program och lämplig hårdvara motages tacksamt.
Har funderat på att rippa mina cd men det har aldrig blivit av.

Jag har inte orkat läsa alt ni har skrivit, om det redan är nämnt kan ni sammanfatta.

EAC är gratis och om inte bäst så förmodligen inte nämnvärt sämre än det som i så fall är bäst.

EAC

Jag har inte köpt en optisk enhet på över 10 år men jag gissar att det inte spelar så stor roll vilken läsare du kör med av de som finns på marknaden nu, om du bara är intresserad av att faktiskt lyssna på musik och inte hårklyva över checksummor.

Det är rätt tråkigt att rippa skivor så jag hade bara rippat sånt som inte finns i någon strömningstjänst. Vissa strömingstjänster har minst lika bra kvalite som CD.

Länk till EAC
Permalänk
Medlem
Skrivet av Teknik:

Hur bra eller dåligt funkar dagens program?
Jag har aldrig rippat ni verkar kunna och därför frågar jag er .

Förslag på rätt program och lämplig hårdvara motages tacksamt.
Har funderat på att rippa mina cd men det har aldrig blivit av.

Jag har inte orkat läsa alt ni har skrivit, om det redan är nämnt kan ni sammanfatta.

Kan bara hålla med 0cool ovan, kör du på Windows så är EAC både gratis och extremt kompetent. Kör du något annat OS så är det cdparanoia som gäller (sen finns det gui:s till den för de som inte vill mecka in en konsol).

På frågan om hur bra dagens program fungerar så är svaret: alldeles utmärkt. Vad gäller hårdvara så tror jag att allt fungerar numera, kan ju starkt rekommendera min Samsung SH-S223B men den slutade nog säljas för över 10 år sedan... Både EAC och cdparanoia kompenserar dock för dålig hårdvara så skulle påstå att det är ett mindre problem.

edit: intressant hur lite det har rört på sig inom detta område, beror ju iofs på att väl ingen kör med optisk media längre, men ändå att min gamla dvd-brännare från 2009 har i princip samma specifikationer och hastigheter som det som jag ser säljs just nu på inet.se så i princip noll utveckling

Visa signatur

|Ryzen 5800x3d|RX 7900XTX Hellhound|Asus Prime X370 Pro|32GiB Corsair 2400MHz CL16 Vengeance|Corsair HX1000i|Fractal Define R5|LG 45GR95QE|Corsair K100|Razer DeathAdder V3 Pro|Ubuntu 23.10|

Permalänk
Medlem
Skrivet av F.Ultra:

Kan bara hålla med 0cool ovan, kör du på Windows så är EAC både gratis och extremt kompetent. Kör du något annat OS så är det cdparanoia som gäller (sen finns det gui:s till den för de som inte vill mecka in en konsol).

På frågan om hur bra dagens program fungerar så är svaret: alldeles utmärkt. Vad gäller hårdvara så tror jag att allt fungerar numera, kan ju starkt rekommendera min Samsung SH-S223B men den slutade nog säljas för över 10 år sedan... Både EAC och cdparanoia kompenserar dock för dålig hårdvara så skulle påstå att det är ett mindre problem.

edit: intressant hur lite det har rört på sig inom detta område, beror ju iofs på att väl ingen kör med optisk media längre, men ändå att min gamla dvd-brännare från 2009 har i princip samma specifikationer och hastigheter som det som jag ser säljs just nu på inet.se så i princip noll utveckling

Det är inte bara noll utveckling, det är full regression, dagens fåtal optiska läsare som finns kvar är magnituder sämre än vad som såldes för 10-15 år sen.

Men skall man absolut ha en så är det USB-läsare som gäller med tanke på att inga vanliga datorlådor har uttag för optisk läsare längre LoL

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-DDR5-6400c32 MSI RTX4080 Ventus 3X OC || CORE i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 Gear1 TUF RTX3080 OC V2 || R7 5800X3D X570S CH8 Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super ||

Permalänk
Rekordmedlem

Det som hänt med hårdvaran är att cd och dvd enheter blivit sämre sedan Plextor slutade göra bra enheter men idag kan man i stället hitta Bluray enheter.

Visa signatur

R5 5600G, Asus ROG STRIX X470-F Gaming, WD SN850X 2TB, Seasonic Focus+ Gold 650W, Aerocool Graphite v3, Tittar på en Acer ET430Kbmiippx 43" 4K. Lyssnar på Behringer DCX2496, Truth B3031A, Truth B2092A. Har också oscilloskop, mätmikrofon och colorimeter.