Bit-perfecte kopieën via een Squeezebox versus een cd-speler

[reMC]

Zover ik het (ook uit andere artikelen en van andere mensen) heb begrepen, introduceert bufferen en reclocken ook weer nieuwe jitter, namelijk die jitter die ontstaat door het verschil tussen de twee klokken (jitter van korte duur, maar veel drastischer). En digitale opnameapparatuur is natuurlijk ook niet jittervrij

[B.J.]

Daar heb je helemaal gelijk in  Wat mij betreft kunnen we deze discussie hiermee dan ook afronden 

peter

Ik heb liever dat jullie doorgaan. Dat 'gedonder' met jitter vind ik maar moeilijk te bevatten en je hoort veel mensen erover 'blaten' (zonder dat ze wellicht exact weten wat het is?). Door juist ook discussies met techneuten leren beide kanten iets, die gelukkig allen muziek liefhebbers zijn.

......... Het rippen is een omzetproces van PCM-stream naar een digitaal bestand. Hierbij wordt de uitgelezen stream gecodeerd in een ander formaat. De jitter die bij het lezen is ontstaan, wordt opgeslagen in het gecodeerde bestand. Daarna belanden we via allerlei, al dan niet draadloze, wegen (die geen verlies veroorzaken) bij de SB of AE. Die moet het geripte bestand opnieuw omzetten in een PCM-stream, met weer nieuwe jitter als gevolg. Daarna moet het middels electronica richting een digitale output worden gestuurd met weer nieuwe jitter-problematiek. Pas vanaf dat moment zijn we net zover als de output van het high end loopwerk, die uiteraard een schoner resultaat heeft opgeleverd. Door betere electronica, een betere uitlezing dan een computerdrive (jitter!) maar vooral ook door het overslaan van twee stappen: omzetten van PCM-stream->computerbestand en van computerbestand->PCM stream.

................

Je bedoelt: van een digitaal PCM-bestand naar een digitaal WAV/RAW-bestand (oid). Dat kan dus idd zonder verlies. Coderingen en omzetting zijn niet van belang, kan je digitaal zonder verlies. En ik heb je al eerder geprobeerd uit te leggen dat er geen plaats is voor jitter in een digitaal bestand, anders dan dat er enen in nullen of andersom zijn omgevallen. Door een aantal verschillende RIPS op verschillende loopwerken te vergelijken kan je vaststellen of dit regulier gebeurt; mijn testen laten dit (anders dan bij sterk beveiligde of berschadigde CD's) tot nu toe niet zien.

Dus nogmaals: waar zit die jitter dan volgens jou in?

...............

Die weddenschap ga ik per direct aan, dat heb ik nl. al geprobeerd. En binair niet zichtbare jitter in een binair bestand, dat is echt onzin.

Vooral dit vind ik interessant. Hier kan maar 1 van beide gelijk hebben en dit is toch wel te bewijzen?

[FrankB]

Jitter is een bewezen en meetbaar fenomeen. En jitter zit alleen in digitale data, zodra het omgezet is naar analoog is er geen jitter meer mogelijk.

[Don_Paul]

Deze discussie begint wel weer gevaarlijk veel op een kabeldiscussie te lijken. Zij die het technisch (theoretisch) benaderen en zij die meer met hun oren luisteren. Hier gaan we natuurlijk nooit uitkomen. Daar kan alleen maar gedonder van komen.

Valt wel mee. Ettepet heeft hier een overduidelijk technische discussie geopend. Ik zie in het hele stuk van alle bijdragers ook alleen technische argumenten- van mijzelf, Ettepet, jouzelf, ReMC, en vpv. Nergens worden er 'kabeldiscussie'-achtige argumenten bijgehaald, nergens worden er steken onder water gegeven - behalve dan nu door jou door te suggereren dat er hier ook 'mensen niet met hun oren luisteren'. Beetje onder de maat, als je het mij vraagt.

Om dan de discussie te invalideren omdat de conclusies je niet aanstaan, tsja ... (doe ik ook even een steek onder water ).

[Don_Paul]

Jitter is een bewezen en meetbaar fenomeen. En jitter zit alleen in digitale data, zodra het omgezet is naar analoog is er geen jitter meer mogelijk.

Kijk, weer een goede inhoudelijke bijdrage die er voor pleit deze discussie open te houden ...

Als je het over het PURE digitale domein hebt zit daar geen jitter in. Ook een computerclock van 1000'en Mhz is niet perfect, ook daar zitten er verschillen tussen de lengte van de ene en de andere puls - maar zolang dat binnen de marges valt is er niets aan de hand.

Jitter komt alleen maar op het grensvlak tussen digitaal en analoog voor - de omzettingsfase. Alles daarvoor kan wel 'timingsfouten' bevatten, maar zolang de data nog interpreteerbaar is analoog aan de broninformatie dan is er niets aan de hand.  Pas bij de omzetting naar analoog zouden er fouten kunnen ontstaan.

[reMC]

Jitter komt alleen maar op het grensvlak tussen digitaal en analoog voor - de omzettingsfase. Alles daarvoor kan wel 'timingsfouten' bevatten, maar zolang de data nog interpreteerbaar is analoog aan de broninformatie dan is er niets aan de hand.  Pas bij de omzetting naar analoog zouden er fouten kunnen ontstaan.

Kan je de 'omzettingsfase' zoals jij die bedoelt wat beter definiëren? Zit het loopwerk daar bijvoorbeeld ook in?

[Don_Paul]

Zover ik het (ook uit andere artikelen en van andere mensen) heb begrepen, introduceert bufferen en reclocken ook weer nieuwe jitter, namelijk die jitter die ontstaat door het verschil tussen de twee klokken (jitter van korte duur, maar veel drastischer).

Interessant - maar dat laatste geloof ik dit niet. Kijk, als je gaat reclocken introduceer je natuurlijk weer 'nieuwe' jitterfouten, daar ben ik het mee eens, want ook je nieuwe clock is niet perfect. Maar je oude jitter is weg, want je hebt gebufferd. Dus ik geloof niet dat het een optelsom wordt, je blijft mi alleen je nieuwe 'jitterfouten' houden.

En digitale opnameapparatuur is natuurlijk ook niet jittervrij

Nee, uiteraard niet. Alleen is het dus de vraag in hoeverre dat uitmaakt in dit geval. Want ook daar wordt gebufferd, waarna wordt gemixed, en pas vanaf de 'master' heb je die problemen 'bevroren'.Totdat je aan de afspeelzijde weer gaat rebufferen, natuurlijk.

[B.J.]

Kan je de 'omzettingsfase' zoals jij die bedoelt wat beter definiëren? Zit het loopwerk daar bijvoorbeeld ook in?

Omzetting klinkt meer als DAC

[Don_Paul]

Vooral dit vind ik interessant. Hier kan maar 1 van beide gelijk hebben en dit is toch wel te bewijzen?

Nou, ik denk dat dit praktisch gezien nog niet zo eenvoudig is. Kijk, we kunnen natuurlijk 100 rips op verschillende configuraties maken en aantonen dat deze gelijk zijn - of niet, maar wat zegt dat dan? Misschien was het wel een uitzonderlijk cleane drager en gaat het daarom altijd 'goed'. Of één van de configuraties was gammel, en daarom gaat het fout. Dus wat toon je ermee aan?

Ik zou het overigens wel een interessant experiment vinden als een x-tal forumleden op hun configuratie een 'rip' van een bekend nummer van exact dezelfde persing zouden maken... ikzelf heb het op kleine schaal getest, maar dat zegt dus nog weinig. Daarom is deze discussie ook zo 'theoretisch'

[FrankB]

Paul, ik volg je niet helemaal. Je zegt in een reactie op mijn post

Als je het over het PURE digitale domein hebt zit daar geen jitter in.

Vervolgens zeg je dit

Kijk, als je gaat reclocken introduceer je natuurlijk weer 'nieuwe' jitterfouten, daar ben ik het mee eens, want ook je nieuwe clock is niet perfect. Maar je oude jitter is weg, want je hebt gebufferd. Dus ik geloof niet dat het een optelsom wordt, je blijft mi alleen je nieuwe 'jitterfouten' houden.

Waarbij je laatste stelling toch over data gaat die volledig in het digitale domein zit, of begrijp ik je verkeerd? Hier vindt nergens conversie plaats. We gaan alleen een digitale reeks reclocken.

[Don_Paul]

Omzetting klinkt meer als DAC

Ja, dat bedoel ik dus. Laat ik het zo formuleren: stel, we hebben een redelijk gammele drager met zeer onregelmatige putjes (m.n. de afstand ertussen). Het loopwerk is ook niet stabiel. De PCM-stream is dan ook niet echt 'clean' als je hem 'analoog' bekijkt'. Dan is er nog steeds niets aan de hand zolang het maar digitaal is, wat 'nog-net-een-1-op-het-juiste-moment' is digitaal gezien hetzelfde als 'precies-1-op-het-juiste-moment'.

Althans, totdat je de DAC ingaat. Dan ZOU het kunnen (geen idee of dat echt zo is, ik heb wel eens om bewijzen/argumenten/onderbouwingen gevraagd, maar ik kan het me iig voorstellen) dat de DAC hier gevoelig is en niet precies de goede analoge omzetting doet, maar iets dat aardig in de buurt zit en toch net wat anders klinkt.

[reMC]

Interessant - maar dat laatste geloof ik dit niet. Kijk, als je gaat reclocken introduceer je natuurlijk weer 'nieuwe' jitterfouten, daar ben ik het mee eens, want ook je nieuwe clock is niet perfect. Maar je oude jitter is weg, want je hebt gebufferd. Dus ik geloof niet dat het een optelsom wordt, je blijft mi alleen je nieuwe 'jitterfouten' houden.

Je zit in de buurt met wat ik denk maar toch nog iets anders.
Ik heb twee punten die ik absoluut NIET kan bewijzen maar uit luisterervaring wil stellen. Namelijk dat reclocken nooit alle soorten jitter kan verwijderen en dat de nieuwe clock ook weer jitter introduceert. De vraag is in hoeverre dat re-clocken dan zin heeft gehad en of dat wel opweegt tegen de jitter die er al was. Er zijn mensen, waaronder ik, die dus zeggen dat de jitter die onstaat tussen de twee clocken veel erger is. Maar nogmaals, ik kan dat niet bewijzen.

Nee, uiteraard niet. Alleen is het dus de vraag in hoeverre dat uitmaakt in dit geval. Want ook daar wordt gebufferd, waarna wordt gemixed, en pas vanaf de 'master' heb je die problemen 'bevroren'.Totdat je aan de afspeelzijde weer gaat rebufferen, natuurlijk.

Dat is inderdaad de vraag. Ik denk dat het van essentieel belang is.

Omzetting klinkt meer als DAC

Daarom juist, een loopwerk kan aanzienlijk veel jitter toevoegen aan de uiteindelijk geluidsweergave.

Daarbij is het heel erg belangrijk dat we jitter niet als een getal moeten zien en daarmee klaar denken te zijn. Jitter is niet 1 getal maar een reeks van zeer complexe vervormingen, de een heeft meer invloed dan de andere en we weten volgens mij niet eens wat die invloed PRECIES is. Het is niet zo dat meer jitter per definitie slechter is. Ik heb het er een tijdje geleden ook al over gehad maar ik geloof dat een apparaat met 500ps aanzienlijk beter kan klinken dan een met 200ps, het hangt af van de soorten jitter die in dat getal verweven zitten, in hoeverre die invloed hebben op het muzieksignaal (meet die INVLOED maar eens...) en daarna nog in hoeverre de gevolgde apparatuur het doorgeeft en we dat uiteindelijk horen.

En er zijn inderdaad genoeg mensen die beweren dat de 'gammelheid' van een loopwerk er niet toe doet zolang er in de dac maar goed gereclockt wordt. Toch kunnen die loopwerken totaal anders klinken als ze dezelfde externe dac hebben gebruikt. (Zelfs na die reclockende dac meten ze nog anders, heb ik gehoord) Ik denk dat het 'gewoon' de truuk is om de jitter in het loopwerk al zo 'mooi' mogelijk te houden, zodat er ook niet veel rotzooi in de dac komt en er dus ook niet gereclockt hoeft te worden.

[)p(]

Ik zou het overigens wel een interessant experiment vinden als een x-tal forumleden op hun configuratie een 'rip' van een bekend nummer van exact dezelfde persing zouden maken... ikzelf heb het op kleine schaal getest, maar dat zegt dus nog weinig. Daarom is deze discussie ook zo 'theoretisch'

Dat is nu precies wat accuraterip doet via het internet. Voobeeldje omdat we toch lekker bezig zijn heb ik zojuist qotsa songs for the deaf geript via mijn desktop en de server hier. Vervolgens een bitcompare gedaan met foobar en jawel hoor weer exact hetzelfde. En niet alleen ik de confidence level van accuraterip gaf 29 aan dus overal precies dezelfde data. (er is minder dan 1 in de biljoen een kans dat bit verschillende rips dezelfde checksum opleveren!)

Wat de discussie verder betreft denk ik dat er een fundamenteel verschil in inzicht is in de aard van een bitstream en de vastelegging daarvan op een cd tussen ons en Audiofiel. Tevens is voor mij jitter "slechts" een temporeel probleem, maar wel een hardnekking probleem want na elke vorm van buffering moet er toch weer ten eerste een heel erg adequate klok gegenereerd worden waar then tweede tot aan de dac geen enkele storing op mag inwerken. En dat is helemaal niet zo makkelijk!

peter

[Don_Paul]

Paul, ik volg je niet helemaal. Je zegt in een reactie op mijn post

Waarbij je laatste stelling toch over data gaat die volledig in het digitale domein zit, of begrijp ik je verkeerd? Hier vindt nergens conversie plaats. We gaan alleen een digitale reeks reclocken.

Ligt aan mij, ik druk me hier idd wat 'kort-door-de-bocht' uit (ik tik me het leplazerus!). Wat ik probeer te zeggen is dat de wijze waarop je naar de data kijkt (waarop je ze gebruikt) hier bepalend is.

Zolang je digitaal blijft is er niets aan de hand. Een digitale bewerking/handeling die een bitje iets later binnenkrijgt dan verwacht heeft hier geen enkele moeite mee, er gaat nog steeds een bitje uit. Misschien weer te laat, misschien zelfs nog wat later, maar op digitaal vlak gaat dit nog steeds goed. Is je handeling echter om de bitjes naar analoog om te zetten, dan kan het wel uitmaken.

Ik bedoel dus: als de stream er zo uitziet:

1     10    0    11   0      0         <-data
  |   |   |   |   |   |   |             <-puls

Dan ziet dat er digitaal uit als 11001100. Net als:

1   1  0   0   1  1   0   0            <-data
   |   |   |   |   |   |   |             <-puls

Alle bitjes vallen in beide gevallen keurig binnen de windows die daarvoor zijn. Sterker nog, als de stream er uitziet als (ik neem als voorbeeld even een threshold van 1v voor een bitje; waarbij <0,3v een 0 is, en >0,7v een 1):


.8  .7    .1 .3    .9  .7   .0    .2     <-data
  |    |    |    |    |    |    |         <-puls

Dan is in het digitale domein nog steeds 11001100.

Analoog gezien zou het echter kunnen dat een DAC hier wat anders bakt van 1 10 0 11 0  0 dan van 1 1 0 0 1 1 0 0.

[Don_Paul]

Ik heb twee punten die ik absoluut NIET kan bewijzen maar uit luisterervaring wil stellen. Namelijk dat reclocken nooit alle soorten jitter kan verwijderen en dat de nieuwe clock ook weer jitter introduceert. De vraag is in hoeverre dat re-clocken dan zin heeft gehad en of dat wel opweegt tegen de jitter die er al was. Er zijn mensen, waaronder ik, die dus zeggen dat de jitter die onstaat tussen de twee clocken veel erger is. Maar nogmaals, ik kan dat niet bewijzen.

Ja, dat is op zich een valide argument. Het zou kunnen dat de reclock meer problemen oplevert dan er in de oorspronkelijke stream zaten. Ik geloof dat zelf niet, omdat een clock VEEL nauwkeuriger is dan je een loopwerk ooit kan krijgen. Maar als je 'reclockclock' gammel is dan kan je er op achteruit gaan. Alleen niet als gevolg van jitter tussen de twee clocks, maar omdat je tweede clock slecht is. Tenzij je aangeleverde stream dusdanig slecht is dat je buiten je windows gaat vallen, maar dan houdt alles op en heb je het over een beschadigde drager...

Ik heb het er een tijdje geleden ook al over gehad maar ik geloof dat een apparaat met 500ps aanzienlijk beter kan klinken dan een met 200ps

Hoe iets klinkt, daar blijf ik vanaf. Ik wil het hier alleen over de theorie hebben.

En er zijn inderdaad genoeg mensen die beweren dat de 'gammelheid' van een loopwerk er niet toe doet zolang er in de dac maar goed gereclockt wordt. Toch kunnen die loopwerken totaal anders klinken als ze dezelfde externe dac hebben gebruikt. (Zelfs na die reclockende dac meten ze nog anders, heb ik gehoord) Ik denk dat het 'gewoon' de truuk is om de jitter in het loopwerk al zo 'mooi' mogelijk te houden, zodat er ook niet veel rotzooi in de dac komt en er dus ook niet gereclockt hoeft te worden.

Als een DAC inderdaad gevoelig is voor binnengekomen timingsfouten in de stream zou dat zomaar kunnen. Ik weet het niet, maar sluit het zeker niet uit.

[FrankB]

Kort samengevat kunnen we zeggen dat de DAC dus best wel eens gevoelig kan zijn voor timingsfouten (jitter), waardoor er klankmatig een verschil optreedt.

Wat ik me nog afvroeg, is dat er vaak wordt gesproken over verschillende soorten jitter. Hoe moet ik dat zien? Timingsproblemen kan ik me nog voorstellen, maar verschillende soorten? Niet dat ik het uitsluit, maar ik ben er gewoon erg benieuwd naar

[)p(]

Wat ik me nog afvroeg, is dat er vaak wordt gesproken over verschillende soorten jitter. Hoe moet ik dat zien? Timingsproblemen kan ik me nog voorstellen, maar verschillende soorten? Niet dat ik het uitsluit, maar ik ben er gewoon erg benieuwd naar

Meestal zijn dat niet echt verschillende "soorten", maar eigenlijk meer verschillende "oorzaken" van temporele afwijkingen in de bitstream.

peter

[reMC]

Wat ik me nog afvroeg, is dat er vaak wordt gesproken over verschillende soorten jitter. Hoe moet ik dat zien? Timingsproblemen kan ik me nog voorstellen, maar verschillende soorten? Niet dat ik het uitsluit, maar ik ben er gewoon erg benieuwd naar

Random jitter, Duty Cycle Distortion, Pulse Width Distortion, Data Dependent jitter, Intersymbol Interference, Sinusoidal jitter, Uncorrelated Bounded jitter etc.

Dat zullen inderdaad oorzaken zijn, die op andere plekken ontstaan met allen een andere invloed op het geluid.

[Don_Paul]

Wat ik er van gelezen heb, gaat idd altijd over verschillende oorzaken. Ik verwacht in volgorde van invloed:
- loopwerk
- MOGELIJK foutcorrectie (heb me altijd afgevraagd in hoeverre correctie nu klankinvloed heeft)
- drager
- DAC?
-

Maar ik mis hier vast nog eea.

[Ettepet]

Hier volgt dan mijn eerste reactie in dit topic:

Audiofiel, allereerst bedankt voor je uitgebreidde reactie.

Helaas had ik gehoopt dat je iets zou zeggen als: "De opslag is niet alleen enen en nullen, het branden van een commerciële audio-cd is meer iets als het omzetten naar een jpeg-plaatje en klopt alleen als je er geen bewerkingsslagen (bijvoorbeeld: rippen) meer op loslaat.  De manier waarop enen en nullen zijn gebrand en de putjes en dalen zelf zijn van belang voor het geluid, net als bij een plaat.  Ergo: alleen een extreem goede cd-speler zou goed kunnen rippen, want extra informatie gaat anders verloren."

Jouw verhaal gaat over automatische errorcorrectie e.d. en je hebt sterke twijfels of verschillende cd- of cd/dvd-spelers wel hetzelfde image opleveren.  Dit laatste is gelukkig vrij makkelijk te achterhalen, en is zover ik begrepen heb van legio sites al aangetoond.  Of al die spelers dan nog steeds dezelfde fundamentele interpretatiefout maken is dan natuurlijk nog niet zeker.  Een verschil wat door het onderling vergelijken kan worden aangetoond.

Ik ben benieuwd wat (toekomstige) shootouts gaan brengen, en ik ben het met je eens dat de conversie naar cd-formaat liefst uit de keten zou moeten.  Jammergenoeg lijkt het erop dat fabrikanten met hun beveiligingen ook in toekomstige formaten bewust verstoringen aanbrengen in het geluid.  Om apparatuur van slag te brengen en als indicatie dat het om kopieerbeveiligd materiaal gaat.

[Dirkie]

Ik lees dat het loopwerk (dvd-cd rom) van de pc voor problemen zorgt. Zijn er geen betere resultaten te halen met een gewoon loopwerk digitaal aan te sluiten op de de digitale ingang van bvb een rme kaart ? Om te zetten naar een bestand op pc en dan af te spelen met een externe dac ?

[)p(]

Ik lees dat het loopwerk (dvd-cd rom) van de pc voor problemen zorgt. Zijn er geen betere resultaten te halen met een gewoon loopwerk digitaal aan te sluiten op de de digitale ingang van bvb een rme kaart ? Om te zetten naar een bestand op pc en dan af te spelen met een externe dac ?

Nee. Dat heeft geen zin. Je verliest sowieso de klok/pulse info wanneer je een bitstream omzet naar een pc data formaat. En zoals je boven kunt terug lezen is het niet moeilijk voor niet beschadigde cd's om de juiste bits te rippen. Betere rips dan bit perfect zijn echt niet mogelijk. Problemen met jitter onstaan pas weer wanneer er weer een bitstream van gemaakt moet worden. Het verschil van mening tussen Don_Paul en mij is dat ik daarbij een redelijk groot probleem verwacht.

peter

[FrankB]

Dus hoeveel jitter er ook in een stream zit, zodra je er pc-data van maakt is die weg?

[)p(]

Dus hoeveel jitter er ook in een stream zit, zodra je er pc-data van maakt is die weg?

Ja.
Zie ook het artikel waar remc naar verwees.

"This jitter is "ephemeral", though, because you can copy this data (irrelevant to the clock), and then play it back again from a more steady medium... and make it sound "good" again. This is not a permanent problem."

"The data is identical... It's important to separate the message (the data) from the messenger (the clock).

It's all in the playback of the last disc in the chain, Paul! The "old" clock is NEVER transferred on each copy, only the data. No matter what speed you write at, there is a new writing master clock in the CD recorder that determines the spacing of the pits on the newly written CD."

peter

[reMC]

Maar er moet dan toch alsnog weer een omzetting plaatsvinden, waar opnieuw jitter aan te pas komt?