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

[FrankB]

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

Als ik vpv goed begrijp, is het zo dat bij het omzetten van een stream naar een pc-data bestand de jitter niet meer bestaat. Dan zijn het alleen nog reeksen 1en en 0en zonder verlies. Ook de afstand is niet meer relevant, omdat het een pc-data file is. Pas wanneer het bestand gestreamed wordt, waarbij het weer van een clock wordt voorzien ontstaan weer jitter problemen. Zowel bij de omzetting lijkt me dan als in de signaalweg als bij de ontvanger and so on and so forth.

[reMC]

Pas wanneer het bestand gestreamed wordt, waarbij het weer van een clock wordt voorzien ontstaan weer jitter problemen. Zowel bij de omzetting lijkt me dan als in de signaalweg als bij de ontvanger and so on and so forth.

Ja, daar doelde ik ook op. Alsnog last van jitter dus, misschien is die jitter wel erger dan wanneer het riedeltje met het loopwerk gevolgd wordt, wie zal het zeggen?

[FrankB]

Ja, daar doelde ik ook op. Alsnog last van jitter dus, misschien is die jitter wel erger dan wanneer het riedeltje met het loopwerk gevolgd wordt, wie zal het zeggen?

Volgens mij blijf je last van jitter houden. Alleen bepaald de kwaliteit van de clock en van alle componenten en signaalbanen hoeveel jitter er is. En wat het beste is, tja. Ik denk op dit moment nog wel de cd-speler. Maar wie weet in de toekomst wel de pc.

[sandervg]

Volgens mij blijf je last van jitter houden. Alleen bepaald de kwaliteit van de clock en van alle componenten en signaalbanen hoeveel jitter er is. En wat het beste is, tja. Ik denk op dit moment nog wel de cd-speler. Maar wie weet in de toekomst wel de pc.

Maar dat is dan toch precies wat de Squeezebox komt doen? Dan haal je de zwakke schakel van de computer eruit (slechte klok, slechte geluidskaart etc.) en wordt het 'jitter vrije' pakketje perfect naar de SB gestuurd en vandaar kan weer jitter ontstaan. Dus als de Squeezebox maar goed is, is er - denk ik - niets aan de hand?

[FrankB]

Maar die squeezebox creeert zelf ook weer jitter. Dus krijg je daar het probleem.

[)p(]

Ja, daar doelde ik ook op. Alsnog last van jitter dus, misschien is die jitter wel erger dan wanneer het riedeltje met het loopwerk gevolgd wordt, wie zal het zeggen?

Inderdaad, daar ben ik het helemaal mee eens. Het omzetten naar een bitstream kan jitter veroorzaken en iedere electrische vervuiling daarna. Precies dezelfde problemen als normaal ook. Vandaar dat ik mij ook heel goed kan voorstellen dat de gemodificeerde versie die jij hebt gehoord een heel stuk beter klinkt.

peter

[Don_Paul]

Precies, het gaat hier weer om de laatste stap - de omzetting naar analoog - waar een slechte klok de problemen kan veroorzaken. Maar, vergeet dat niet, als die voorgaande stappen die ook problemen kunnen veroorzaken zijn dan uitgesloten. In het geval van de SB staat en valt het theoretische resultaat dus met die klok; bij een normaal loopwerk moet je de stappen ervoor ook meenemen.

Overigens, de gemodificeerde versie zou m.n. de analoge uitgangen aanpakken, zo heb ik begrepen.

Gevoelsmatig verwacht ik dat de combinatie SB -> HELE goede DAC met reclock de beste resultaten geeft, zelfs beter dan de meeste dedicated loopwerken die op diezelfde DAC aangesloten zitten.

[FrankB]

Wel interessant. Want dat zou betekenen dat wanneer er in een systeem vlak voor de DAC zo'n omzetting wordt geintroduceerd het loopwerk etc niet meer boeit. Ieder loopwerk dat foutloos een cd kan uitlezen zou volgens die theorie volstaan. Klinkt te mooi om waar te zijn

[Ettepet]

Wel interessant. Want dat zou betekenen dat wanneer er in een systeem vlak voor de DAC zo'n omzetting wordt geintroduceerd het loopwerk etc niet meer boeit. Ieder loopwerk dat foutloos een cd kan uitlezen zou volgens die theorie volstaan.

Zie ook opening post...

[)p(]

Wel interessant. Want dat zou betekenen dat wanneer er in een systeem vlak voor de DAC zo'n omzetting wordt geintroduceerd het loopwerk etc niet meer boeit. Ieder loopwerk dat foutloos een cd kan uitlezen zou volgens die theorie volstaan. Klinkt te mooi om waar te zijn

Ik heb al aangegeven dat ik denk dat de problemen in principe niet eens zoveel anders zullen uitvallen. Ik verwacht wel dat we meer en meer oplossingen zullen zien waar de conversie zo laat mogelijk wordt gedaan en dan vaak nog in samenwerking met ruimte correctie algoritmen.  Een mooi voorbeeld is de Lyngdorf tda 2200 met de roomperfect add-on. Ik denk echt dat dergelijke systemen de toekomst hebben. Maar dan hopelijk ongeveer voor de helft van de prijs of zo...

peter

[Don_Paul]

Ieder loopwerk dat foutloos een cd kan uitlezen zou volgens die theorie volstaan. Klinkt te mooi om waar te zijn

Ik denk toch dat dit de kant is waar we meer en meer naartoe gaan. Ook in de high-end sector zijn er al verschillende loopwerken die bufferen, en er wordt sowieso al regelmatig van PC-loopwerken gebruik gemaakt. Ik verwacht alleen dat een 'alles-in-1' oplossing een STUK moeilijker op high-end niveau te krijgen (allemaal extra vervuiling) is dan een gescheiden oplossing waarbij rippen en afspelen in aparte units plaatsvind.

Het allergrootste obstakel zie ik echter in het toenemende gebruik van DRM-technieken die dit onmogelijk maken. Voor CD valt dit nog wel mee, maar het zo behandelen van SACD/DVD-A/Blue Ray/HD-DVD gaat al een stuk lastiger worden.

[reMC]

Ieder loopwerk dat foutloos een cd kan uitlezen zou volgens die theorie volstaan. Klinkt te mooi om waar te zijn

Dat loopwerk komt nooit

[Don_Paul]

Ja hoor, die loopwerken zijn er al. Als je maar buffert.... daar ging het nu net om.

Overigens, ik heb vanochtend die link door zitten lezen die je zelf gepost hebt. Bevat veel goede informatie over jitter; en daar precies hetzelfde verteld als waar we het hier over hebben - het gaat m.n. over de laatste stap in de keten, die moet goed zijn.

Er wordt daar zelfs geclaimd dat het mogelijk is een jittervrije keten op te leveren; geen idee hoe ze dat voor elkaar willen krijgen, lijkt me onmogelijk omdat je altijd een clock moet hebben met al zijn onnauwkeurigheden (of je het ook hoort is dan weer een ander verhaal).

Wat overigens ook leuk leesvoer is: er wordt daar iig een hypothese gegeven waarom foutcorrectie ook invloed uit zou kunnen oefenen op de uiteindelijke geluidskwaliteit. De oorzaak wordt daar gezocht in m.n. de ' analoge' invloeden van de correctiecircuits die via voedingen weer in de rest van de keten (zoals de clock) terecht komen. Helaas verder niet getest, wel een aardige hypothese.

[)p(]

Wat overigens ook leuk leesvoer is: er wordt daar iig een hypothese gegeven waarom foutcorrectie ook invloed uit zou kunnen oefenen op de uiteindelijke geluidskwaliteit. De oorzaak wordt daar gezocht in m.n. de ' analoge' invloeden van de correctiecircuits die via voedingen weer in de rest van de keten (zoals de clock) terecht komen. Helaas verder niet getest, wel een aardige hypothese.

Bedenk ook dat elke operatie tijd kost en levert synchronisatie problemen op... De jitter die je zo introduceert kan erger zijn dan de hoeveelheid omgevallen bitjes die je corrigeert...

peter

[FrankB]

Ja hoor, die loopwerken zijn er al. Als je maar buffert.... daar ging het nu net om.

reMC bedoeld dat er altijd leesfouten worden geintroduceerd, dat los je met bufferen niet op.

[redfox001]

Ja hoor, die loopwerken zijn er al. Als je maar buffert.... daar ging het nu net om.

Overigens, ik heb vanochtend die link door zitten lezen die je zelf gepost hebt. Bevat veel goede informatie over jitter; en daar precies hetzelfde verteld als waar we het hier over hebben - het gaat m.n. over de laatste stap in de keten, die moet goed zijn.

Er wordt daar zelfs geclaimd dat het mogelijk is een jittervrije keten op te leveren; geen idee hoe ze dat voor elkaar willen krijgen, lijkt me onmogelijk omdat je altijd een clock moet hebben met al zijn onnauwkeurigheden (of je het ook hoort is dan weer een ander verhaal).

Wat overigens ook leuk leesvoer is: er wordt daar iig een hypothese gegeven waarom foutcorrectie ook invloed uit zou kunnen oefenen op de uiteindelijke geluidskwaliteit. De oorzaak wordt daar gezocht in m.n. de ' analoge' invloeden van de correctiecircuits die via voedingen weer in de rest van de keten (zoals de clock) terecht komen. Helaas verder niet getest, wel een aardige hypothese.

Ja die hypothese wordt door meer experts gesteund ook bij Plextor. Hoe meer schakels in de keten hoe meer storing op de voeding en de grondvlakken. Vaak worden de digitale en de analoge voeding in een cd speler gescheiden om deze storing te ontlopen. Een digitale bron weergeven is zo moeillijk omdat alle referentie spanningen vervuild raken. Volgens mij is de beste manier om dit op te lossen om een zeer stabiel eenvoudig loopwerk te hebben dat de signalen ongebufferd zo snel mogelijk naar de dac brengt en dat liefst galvanisch gescheiden van de dac is. En natuurlijk veel goede ontstorings condensatoren op de juiste plaatsen maar dit is een onderwerp waar iedere kok zijn eigen keukengeheimen heeft.

Ik hoop nog op verbetering van spelers zonder loopwerk zoals de ipod die bovendien een hoge kwaliteit clock en electronica aan boord hebben. Is dat ijdele hoop? Waarom zijn die er nog niet?

[Don_Paul]

reMC bedoeld dat er altijd leesfouten worden geintroduceerd, dat los je met bufferen niet op.

Nou, gelukkig hebben we die leesfouten niet altijd. Die hebben we in principe alleen bij extreme problemen met de drager; en dat is over het algemeen geen probleem. Timingsproblemen met uitlezen, die hebben we dus wel altijd, maar die zijn met buffering dus op te lossen.

[Don_Paul]

Ik hoop nog op verbetering van spelers zonder loopwerk zoals de ipod die bovendien een hoge kwaliteit clock en electronica aan boord hebben. Is dat ijdele hoop? Waarom zijn die er nog niet?

Chord heeft iets, weliswaar ook nog met een loopwerk, dat aan die specificatie voldoet. Hangt wel een prijskaartje aan...

[reMC]

Nou, gelukkig hebben we die leesfouten niet altijd. Die hebben we in principe alleen bij extreme problemen met de drager; en dat is over het algemeen geen probleem. Timingsproblemen met uitlezen, die hebben we dus wel altijd, maar die zijn met buffering dus op te lossen.

Een timingsprobleem bij het uitlezen noem ik ook een leesfout Bovendien weet ik niet zeker of elk loopwerk wel alle bitjes uberhaubt leest. En bedoel je bufferen zonder re-clocken? Wat heeft dat voor nut

[reMC]

Gevoelsmatig verwacht ik dat de combinatie SB -> HELE goede DAC met reclock de beste resultaten geeft, zelfs beter dan de meeste dedicated loopwerken die op diezelfde DAC aangesloten zitten.

Ik heb de combinatie gemodificeerde SB met een voor mij zeer goede dac gehoord (non-oversampling dac door Cees Pel) en die haalt het NET niet bij een standaard 47labs loopwerk. De betere loopwerken van Cees Pel gaan de SB met gemak voorbij, op diezelfde dac.

En nee, deze dac buffert en re-clockt niet, tot nu toe zijn de resultaten alleen maar minder dan wanneer het wordt weggelaten.

Hier een stukje dat elders op het forum staat, door void, eigenaar van Audio-Cube en samenwerkend met zojuist genoemde Cees Pel. Zij menen dus dat bufferen en reclocken op hoog niveau geen oplossing is.

In theorie zou je deze jitter kwijt kunnen raken door bijv. te bufferen en te reclocken, in dat geval zou de CDPRO perfect zijn, maar in praktijk is er nog geen apparaat gebouwd (zover ik weet) dat hierin slaagt. Alle jittercorrectie kastjes/apparatuur die we geprobeerd hebben kunnen de kwaliteit van de meeste loopwerken enigsinds verbeteren, maar ze halen niet het niveau van een goed loopwerk. Bij een goed loopwerk geven ze juist een verslechtering, de Apogee Big Ben Masterclock (die in veel studio's wordt gebruikt) verminderde de kwaliteit van een gemodificeerd Shigaraki loopwerk aanzienlijk.
De digitale signalen in een CD loopwerk/DAC zijn hoogfrequent, het geluidsignaal is 44100 maal per seconde vastgelegd op CD, links en rechts, plus een hele hoop extra bits. De data wordt o.a. verstuurd met zo'n 3MHz, maar met een blokgolf (0/1), de hoge stijgsnelheid creeert nog heel veel hogere frequenties. Digitale signalen vormen ook een agressieve belasting op de voeding(en). Alles stoort op elkaar, CD apparatuur is eigenlijk een grote puinhoop, enorm ingewikkeld om een beetje zuiver te krijgen. Jitter is als een virus, het jitterpatroon op de ingang verschijnt altijd weer op de uitgang, hier ligt nog een grote uitdaging voor ontwerpers. Denk niet dat je met een 'super'-clock inbouwen veel problemen kunt oplossen, in onze ervaring worden de problemen vaak juist groter. De enige manier is stap-voor-stap elk probleem oplossen in de hele keten, en dit doe je niet in een paar weken (wij niet in ieder geval), Cees Pel is al zo'n 2 jaar bezig met het Shigaraki loopwerk (met diverse prototypes). Hij zegt dat het net zo is als met de plaat: als het bij de naald mis gaat wordt het nooit meer wat. En bij de meeste CD loopwerken gaat het bij de laser al mis: focus en tracking van meeste lasers beinvloeden elkaar (mechanisch). Opvallend vond ik om te lezen dat de ontwerper van de CDM4 en CDM9 voor Audiomeca een loopwerk heeft ontwikkeld: ze gebruiken een Sanyo laser, die dit probleem niet heeft.
De problemen in de CDPRO zijn in ieder geval ook niet op te lossen met een hele goede clock, alhoewel het wel iets verbetert, ligt de bottleneck duidelijk elders, waar weten we niet (en Zanden heeft het wat mij betreft ook niet gevonden, alhoewel hij daar anders over denkt).

[Don_Paul]

Een timingsprobleem bij het uitlezen noem ik ook een leesfout

En dat is dan dus een foute benoeming, want een leesfout zorgt voor incorrecte reproductie van de vastgelegde data, en dat is bij een timingsprobleem niet het geval, dan heb je een correcte reproductie, alleen op een iets-eerder-of-later moment in de tijd dan je verwacht of wens. Dus nog een keer - zolang je geen clockdata verstuurt of vastlegt KAN je geen jitter introduceren of 'bewaren', want waar zouden die timingsverschillen dan moeten zitten? In het 'zwart'  tusseen de bitjes?

Bovendien weet ik niet zeker of elk loopwerk wel alle bitjes uberhaubt leest.

Mja, daarvoor hebben we nu juist die standaards, maar het is idd niet uit te sluiten dat een aantal zotten op deze wereld hebben besloten dat ze niet alle bitjes nodig hebben. Overigens zou me dat wel zeer verbazen, temeer daar je die data (a) voor de muziekweergave, en (b) voor de errorcorrectie nodig hebt. Lezen zal je ze dus; maar je kan er daarna wel een paar weglaten, als je dat wilt.

En bedoel je bufferen zonder re-clocken? Wat heeft dat voor nut

Bufferen zonder reclocken heeft zin als je doel niet is de muziek af te spelen, maar te rippen. Dan wil je alleen de data hebben om de clock er later 'overheen' te zetten.

Ik heb de combinatie gemodificeerde SB met een voor mij zeer goede dac gehoord (non-oversampling dac door Cees Pel) en die haalt het NET niet bij een standaard 47labs loopwerk. De betere loopwerken van Cees Pel gaan de SB met gemak voorbij, op diezelfde dac.

Zou best kunnen, zeker als die loopwerken van zichzelf al een goede clock hebben, dat ze 'beter' klinken. Overigens, ik stel beter klinken dus niet gelijk aan beter presteren; ik heb het hier nooit over geluidskwaliteit gehad, dat is subjectief en persoonlijk.


Oh, ik was nog een link vergeten: ik weet niet of je die kent?

http://www.cdrfaq.org/

Hier staat redelijk goed beschreven op welke wijze de CD-data nu exact wordt vastgelegd.