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

[Ettepet]

Onderstaande discussie komt van elders:

Wel zal een oplossing zoals de SB een stuk makkelijker hoog scoren dan een cd-speler die het onhandige "red book" formaat eerst moet zien te fatsoeneren.

Wat je bedoelt met 'het onhandige red book formaat fatsoeneren'.
Ik snap een aantal dingen niet.
1. Wat doet de SB anders dan een cd-speler? De basis is en blijft de CD die ingelezen moet worden dus de basis is en blijft het red book formaat.
2. Waarom zou een SB 'een stuk makkelijker hoog scoren dan een cd-speler'? De dacs in het apparaatje zijn immers niet echt om over naar huis te schrijven... althans dat is de mening van een aantal personen.
3. Wat is er onhandig aan het red book formaat?
D. Wat moet er gefatsoeneerd worden?

Beunky,

1. De CD wordt inderdaad door de computer ingelezen.  Blijkbaar zet jij je vraagtekens of de computer dat (met enige moeite) foutloos kan.  Graag hoor ik welke zwakte er volgens jou in al die (computer-) cd/dvd-spelers tesamen zit waardoor een slim programma (met voldoende tijd en aandacht) NIET een bit-perfecte kopie kan ophoesten.  B.t.w.: Er is een database met checksums waarmee je je kopie kunt testen op correctheid.

2. Een Squeezebox-achtige hoeft een flink deel aan hardware niet te hebben, want hij krijgt een datastroom aangereikt en hoeft deze alleen te bufferen in een (flink) buffer.  Vanaf dat moment is er een nauwkeurige klok nodig, een goede DAC en wat extra hardware om het geheel goed te laten verlopen.  Het hele fysieke loopwerk en toebehoren tot aan de klok van een normale cd-speler ontbreekt.  Omdat het probleem is teruggebracht tot bufferen (=tijdig beschikbaar hebben), een precieze klok en een DAC is een SqueezeBox stukken voordeliger, en ben je alle jitter tot aan de klok en DAC in zijn geheel kwijt (bij een bit-perfecte kopie).

3. Met het redbook formaat doel ik op de oorspronkelijke cd-standaard waar we nu als basis mee zitten.

4. Het fatsoeneren is alles wat er in een cd-speler elke keer weer nog moet gebeuren om zo "bit-perfect" mogelijk te lezen en goed ge-timed (!) door te geven, en met een bit-perfecte kopie vanaf je harde schijf via een SqueezeBox (in principe) niet.

[)p(]

2. In principe heb je gelijk dat het met een apparaat als de sb een stuk goedkoper kan. En met de sb2 hebben ze bij slimdevices echt geprobeerd om zoveel mogelijk aan de audiofiele wensen van gebruikers van de eerste sb tegenmoet te komen. Veel info daarover op het slimdevices forum. Echter wat ook duidelijk is dat ze veel compromissen moesten sluiten om de prijstelling (onder de 300$) zo te houden dat het ook het massa produkt kon blijven wat hun voor ogen stond. Ik denk dat er dan ook nog heel wat winst te boeken is met de modificaties waar Remc op wees in de andere thread. Ben daar zelf ook erg benieuwd naar.

peter

[beunky]

Onderstaande discussie komt van elders:

Beunky,

3. Met het redbook formaat doel ik op de oorspronkelijke cd-standaard waar we nu als basis mee zitten.

Op de rest hoop ik later nog even in te gaan (zaterdag), ik heb er nu ff geen tijd voor helaas
Maar hier heb ik nog wel ff wat alvast, ik snap heel goed wat het red book formaat is
Maar je geeft niet aan wat er onhandig aan is en dat is wel iets dat je stelde en ik dus graag opgehelderd wil hebben omdat ik niet inzie wát er dan onhandig aan is. Ik ben bekend met de beperkingen van het formaat en alles, maar daar gaat het niet over, dat is niet wat er bedoeld wordt.

[Audiofiel]

Wat de aanleiding ook is, om de een of andere reden begrijp jij (en zo te zien een paar anderen) niet de kracht van een digitaal loopwerk.

Ik denk dat ik precies de kracht begrijp van een digitaal loopwerk. Zodra je de muziek direct vanuit de digitale bron zou kunnen laten horen – en daarmee een aantal cruciale stappen kunt overslaan - zou je een enorm voordeel behalen.

In theorie is dat dus allemaal prachtig, maar in de praktijk hebben we niet zo'n systeem. Er moeten allerlei stappen worden doorlopen. Van opname, via (meerdere malen) mengtafel naar een master tape. Daarna van master een kopie, van die kopie wordt een patrijs gemaakt om tot productie over te gaan. Daarna worden de CD's van de patrijs gemaakt: de eerste hebben scherpte putje, de laatsten hebben vage putjes... Vervolgens belanden we pas bij de concument in huis in een doosje. Al deze stappen hebben de originele uitvoering veranderd en de opname op de CD is al lang niet meer van de kwaliteit die op de eerste opname stond...

Nu zitten we thuis met die CD in onze handen en willen we die opnieuw digitaliseren en misschien zelfs draadloos overbrengen naar de stereoset. Weer nieuwen stappen dus. Eerst gaan we de CD rippen, al dan niet met een programma dat de sectoren meerdere keren uitleest. We moeten namelijk de PCM-stream om gaan zetten in een computerbestand. Vervolgens slaan we het aldus verkregen bestand op, op een harde schijf. Zodra we een AIFF, WAV, Losslless, AAC of MP3 hebben kunnen we het bestand zonder problemen zo vaak kopiëren als we willen zonder enig kwaliteitsverlies: het is immers een computerbestand geworden. Dit bestand kunnen we vervolgens draadloos laten doorsturen naar een SB of Airport Express, waar het opnieuw wordt omgezet in een PCM-stream. Die sturen we dan met digitaal coax of optisch naar een DAC.

Nu beweer jij dat simpelweg het nauwkeuriger gaan uitlezen van de audio-CD op een computer een beter resultaat op gaat leveren dan een goed CD-loopwerk. Dat zal nooit lukken: allereerst vergeet je nu de extra stappen die nodig zijn in dit proces. 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.

Wanneer we nu van de originele band direct een computerbestand hadden gehad, hadden we zeker een beter bestand gehad en was het CD-loopwerk verslagen. Maar dat hebben we niet. We moeten de audio-CD gebruiken die al vele malen minder is dan de originele tape en twee fors verliesgevende omzet-stappen doorgaan via een rip-bestand.

Dat je een voordeel kunt behalen door je audio CD meerdere malen te lezen met een programma als Exact Audio Copy, wil ik best geloven. Maar de behaalde winst moet ook niet overtrokken worden. Ook al lees je 10x een bepaalde sectie uit, als er een bitje foutstaat (doordat de drive het niet goed leest of het putje niet perfect is of doordat de schijf is beschadigd) dan ga je die informatie niet meer terug verdienen. Op het laatst slaat toch de foutcorrectie toe (die ook in dat high end loopwerk zit) en wordt er informatie bijverzonnen. Daarnaast is er veel verschil tussen uitlezen met een CD-speler en een CD/DVD-speler, dus het lijkt mij niet meer dan logisch dat je dan ook dezelfde verschillen krijgt bij het rippen met een DVD/CD-drive. Je zou dan ook een dedicated CD-drive moeten gebruiken en die fixeren op 1-speed.

De vraag is wat er gebeurt als je op twee verschillende computers een bestand op die manier gaat rippen. Ik durf te wedden dat ze niet 100% binair gelijk zullen zijn (afgezien van de opgeslagen, dus binair niet zichtbare jitter), ieder geript bestand heeft wel 'iets' unieks. En dus een andere klank. Ik denk dat weinig mensen het verschil gaan horen tussen een geripte AIFF/WAV of een 10x op 1-speed met EAC ingelezen bestand. Waarom? Omdat we naast de superkleine verschillen tussen deze twee bestanden te maken hebben met de veel forsere invloed van het tweemaal omzetten en de lagere kwaliteit van de electronica en digitale uitgang van de SB of AE.

[Audiofiel]

Ik heb inderdaad eerder gezegd dat ik de Squeezebox erg mooi vond. Maar ik begrijp werkelijk niet hoe ik vergeten te zeggen ben dat het de gemodificeerde versie is die voor mij veel beter is (wel dezelfde ic's nog) dan veel loopwerken (mits aangesloten op een goede dac!). In die versie zijn overbodige circuits uitgeschakeld en worden er andere elco's gebruikt etc.. Standaard is hij lang zo mooi niet en weet ik inderdaad niet of hij de betreffende loopwerken 'wegspeelt', sorry voor de verwarring; mijn fout!

Gemodificeerd of niet, zie mijn post hierboven. Je kunt toch onmogelijk door mindere hardware en twee extra omzet-stappen een beter resultaat bereiken.

[sandervg]

Dit zou betekenen dat de discussie wordt teruggevoerd op de omzetting van het audiobestand op de CD naar een computerbestand, want de overige stappen gelden in gelijke mate voor een highend loopwerk: je kunt de digitale uitgang van de SB modiferen, zodat deze geljik is aan die van een duur loopwerk en fouten op een CD (bv. door beschadigingen) zullen door elke drive niet teruggewonnen kunnen worden. Het enige wat je kunt stellen is dat een programma als EAC, mijns inziens, het zeker niet slecht hoeft te doen dan een highend loopwerk. De drive is misschien veel slechter, maar dat wordt dan keurig gecompenseerd door het vaker uitlezen van de informatie.

De omzetting van audiobestand naar een computerbestand, daar heb ik geen verstand van. Ik weet niet of de 'gebruikelijke' jitter (dus fouten in het tijdsdomein bij het uitlezen van de CD) ook worden opgeslagen in het computerbestand. Ik denk wel dat je daarna geen jitter meer toevoegd tot het moment dat het over de digitale uitgang wordt gegooid bij de SB (die je dus gelijk kunt maken aan die van een goed loopwerk --> dus niet méér jitter dan bij het loopwerk).

[Audiofiel]

Dit zou betekenen dat de discussie wordt teruggevoerd op de omzetting van het audiobestand op de CD naar een computerbestand, want de overige stappen gelden in gelijke mate voor een highend loopwerk: je kunt de digitale uitgang van de SB modiferen, zodat deze geljik is aan die van een duur loopwerk...

Je kunt de uitgang verbeteren, de voeding verbeteren, de CD vaker lezen... Maar je blijft altijd twee maal omzetten. Twee maal die je dus overslaat op je high-end CD-loopwerk.

De drive is misschien veel slechter, maar dat wordt dan keurig gecompenseerd door het vaker uitlezen van de informatie.

Acht keer geel 'zien' en twee keer oranje helpt weinig als de eigenlijke kleur rood was. Vaker uitlezen van net-niet-correcte informatie (ook jitterfouten) levert geen voordelen op. Het uitlezen van een audio-stream heeft niet veel van doen met synchrone computerbits die keurig achter elkaar staan en in willekeurige volgorde kunnen worden uitgelezen.

Een DVD/CD-combidrive gebruikt een ander mechanisme en (vrijwel altijd) een andere kleur laser dan een CD-only-drive.

[reMC]

Gemodificeerd of niet, zie mijn post hierboven. Je kunt toch onmogelijk door mindere hardware en twee extra omzet-stappen een beter resultaat bereiken.

Dat zou je denken ja... Wat bedoel je met de mindere hardware? Het IC? Misschien is die helemaal niet zo slecht als er gedacht wordt, ik weet wat ik heb gehoord en dat er dus mogelijk mee is

[Don_Paul]

In theorie is dat dus allemaal prachtig, maar in de praktijk hebben we niet zo'n systeem. Er moeten allerlei stappen worden doorlopen. Van opname, via (meerdere malen) mengtafel naar een master tape. Daarna van master een kopie, van die kopie wordt een patrijs gemaakt om tot productie over te gaan. Daarna worden de CD's van de patrijs gemaakt: de eerste hebben scherpte putje, de laatsten hebben vage putjes... Vervolgens belanden we pas bij de concument in huis in een doosje. Al deze stappen hebben de originele uitvoering veranderd en de opname op de CD is al lang niet meer van de kwaliteit die op de eerste opname stond...

Hoe zal ik dit vriendelijk formuleren...

Het is niet relevant of putjes al dan niet scherp of rond zijn. Dat is nu juist de definitie van digitaal, wel-of-niet en niet een-beetje-wel-of-niet. Bij al die stappen KUNNEN (afhankelijk van de gebruikte methode) er op ANALOOG niveau wel verschillen zijn, maar dat is niet relevant als het nulletje nog maar net herkenbaar is als nulletje en niet als eentje, er is geen verschil tussen digitale nulletjes.

Bovendien, al die stappen die je nu beschrijft vinden altijd plaats en hebben dus geen invloed op de vergelijking SB<->Highend loopwerk.  Als een SB al beter zou werken moet hij dat onder dezelfde voorwaarden doen.

Nu beweer jij dat simpelweg het nauwkeuriger gaan uitlezen van de audio-CD op een computer een beter resultaat op gaat leveren dan een goed CD-loopwerk. Dat zal nooit lukken: allereerst vergeet je nu de extra stappen die nodig zijn in dit proces. 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.

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?

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.

Wederom niet mee eens.

Daarna moet het middels electronica richting een digitale output worden gestuurd met weer nieuwe jitter-problematiek.

Ja, daar zou idd in principe een probleem kunnen ontstaan. Net als bij een high-end loopwerk, natuurlijk, maar daar zou eea beter geregeld kunnen zijn.

Pas vanaf dat moment zijn we net zover als de output van het high end loopwerk, die uiteraard een schoner resultaat heeft opgeleverd.

Hier laat je een heel stuk argumentatie achterwege. Hoezo uiteraard? Je laat voor het gemak de hele uitlezing van het loopwerk achterwege. Ook je aansluitmoment klopt niet, de omzetting van naar een digitale output is ook bij het highend loopwerk aanwezig. Maar juist DAAR zou ik verbeteringen tov de SB verwachten, daar is wat te halen, in het proces daarvoor betwijfel ik dat ten zeerste.

Dat je een voordeel kunt behalen door je audio CD meerdere malen te lezen met een programma als Exact Audio Copy, wil ik best geloven. Maar de behaalde winst moet ook niet overtrokken worden. Ook al lees je 10x een bepaalde sectie uit, als er een bitje foutstaat (doordat de drive het niet goed leest of het putje niet perfect is of doordat de schijf is beschadigd) dan ga je die informatie niet meer terug verdienen.

Als de fout idd niet meer hestelbaar is door de foutcorrectie, dan ben je dat bitje kwijt. Maar alleen onder de voorwaarde ben 'fors beschadigde dragers'. De normale foutcorrectie is voor CD's ook 'lossless', door redundante informatie kan het originele bitje weer terugberekend worden - zolang je maar niet buiten de reguliere foutmarges valt.

Daarnaast is er veel verschil tussen uitlezen met een CD-speler en een CD/DVD-speler, dus het lijkt mij niet meer dan logisch dat je dan ook dezelfde verschillen krijgt bij het rippen met een DVD/CD-drive. Je zou dan ook een dedicated CD-drive moeten gebruiken en die fixeren op 1-speed.

Ook dat heb ik geprobeerd, maar dat is niet het geval, deze leveren een bit-gelijk bestand op (nogmaals, uitgaande van niet beschadigde dragers).

De vraag is wat er gebeurt als je op twee verschillende computers een bestand op die manier gaat rippen. Ik durf te wedden dat ze niet 100% binair gelijk zullen zijn (afgezien van de opgeslagen, dus binair niet zichtbare jitter), ieder geript bestand heeft wel 'iets' unieks.

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.

[reMC]

Don Paul, overal waar 0'en en 1'en zitten kan ook jitter zijn. Daarom kan jitter ook verschil maken: de nullen en enen zijn niet helemaal digitaal, het tijdstip van verzenden is analoog en daar speelt jitter een rol.

[)p(]

De vraag is wat er gebeurt als je op twee verschillende computers een bestand op die manier gaat rippen. Ik durf te wedden dat ze niet 100% binair gelijk zullen zijn (afgezien van de opgeslagen, dus binair niet zichtbare jitter), ieder geript bestand heeft wel 'iets' unieks.

Dit is dus niet het geval. Je kunt dit zelf testen door met eac dezelfde cd te rippen op twee verschillende computers. Ik heb dat zelf gedaan en zoals al eerder gezegd het resultaat was bit perfect gelijk.
Daarnaast is er een plugin genaamd accuraterip die je met eac kunt gebruiken. Er wordt dan een checksum aangemaakt en die kun je via een internet database vergelijken met anderen die dezelfde cd geript hebben. Is de checksum hetzelfde dan heb je precies en dan ook precies dezelfde rip. Het beste is om je uitkomsten met een populaire cd te vergelijken die al vele malen geript is. En ook daaruit kwam in mijn geval dat mijn test rips precies dezelfde checksums hadden.

peter

[Don_Paul]

Don Paul, overal waar 0'en en 1'en zitten kan ook jitter zijn. Daarom kan jitter ook verschil maken: de nullen en enen zijn niet helemaal digitaal, het tijdstip van verzenden is analoog en daar speelt jitter een rol.

Sorry, maar dit is echt flauwekul. Lees even goed, het gaat hier om in een bestand opgeslagen nullen en enen, niet om een stream met nullen en enen.

[reMC]

Sorry, maar dit is echt flauwekul. Lees even goed, het gaat hier om in een bestand opgeslagen nullen en enen, niet om een stream met nullen en enen.

Een cd bevat ook jitter

[Don_Paul]

En waar blijft dit jitter dan als je hem uitleest en in een bestand op een harddisk opslaat? Liggen de bitjes dan soms niet op de goede afstand van elkaar?

[reMC]

En waar blijft dit jitter dan als je hem uitleest en in een bestand op een harddisk opslaat? Liggen de bitjes dan soms niet op de goede afstand van elkaar?

Als je dat bestand met jitter opslaat, blijft de jitter daar in zitten en krijg je dan nooit meer weg.

[)p(]

Een cd bevat ook jitter

Zover ik het begrepen heb, ja en nee. Ja vanwege het feit dat de putjes niet exact hetzelfde zijn en de afstanden niet exact gelijk zijn vanwege de persing. Nee omdat dit een probleem is van uitlezen. Het is domweg erg moeilijk om van de cd de gelezen bitjes precies getimed de dac in te krijgen...ie temporele spatiering van de bits. Eventuele foutcorrectie zorgt er in het algemeen wel voor dat de juiste bits de dac bereiken, maar dat kan een dergelijke temporele afwijking niet verhelpen. Daarvoor zijn andere maatregelen zoals bijvoorbeeld buffers in combinatie met reclocking nodig.

peter

[reMC]

Hier wordt wat geschreven over jitter op cd's. Zeker de moeite waard om te lezen!

En jitter op een cd is natuurlijk iets anders dan de jitte die 'ontstaat' bij het uitlezen van een cd door een loopwerk.

[Don_Paul]

Eventuele foutcorrectie zorgt er in het algemeen wel voor dat de juiste bits de dac bereiken, maar dat kan een dergelijke temporele afwijking niet verhelpen. Daarvoor zijn andere maatregelen zoals bijvoorbeeld buffers in combinatie met reclocking nodig.

Of, waar dit over gaat, door je PC als buffer te gebruiken. Die jitter zit dan dus niet in het opgeslagen bestand. Nogmaals: daarin zitten alleen 1-0 combinaties, geen tijdsinformatie. ALS er al een door verschil zou zijn, moet dit tot uiting komen door een binair verschil op het bestand. En die treden onder normale omstandigheden dus niet op.

Het is overigens ook niet juist om te stellen dat de CD 'jitter bevat'. De CD bevat louter digitale data; door de beperkingen bij uitlezen kan je hier timingsproblemen (= jitter) krijgen, maar dat is dus niet iets dat de CD zelf bevat.

[Don_Paul]

Hier wordt wat geschreven over jitter op cd's. Zeker de moeite waard om te lezen!

Is idd een leuk stukje. Twee punten haal ik er even uit:
- Bob heeft het over een theorie over de oorzaken van Jitter. Strikt gesproken is wat hij hier formuleert geen theorie, maar een hypothese
- En wat draagt Bob aan als potentieele oplosing voor de leesproblemen: Een op PC-technologie gebaseerde oplossing...

[)p(]

Of, waar dit over gaat, door je PC als buffer te gebruiken. Die jitter zit dan dus niet in het opgeslagen bestand. Nogmaals: daarin zitten alleen 1-0 combinaties, geen tijdsinformatie. ALS er al een door verschil zou zijn, moet dit tot uiting komen door een binair verschil op het bestand. En die treden onder normale omstandigheden dus niet op.

Het is overigens ook niet juist om te stellen dat de CD 'jitter bevat'. De CD bevat louter digitale data; door de beperkingen bij uitlezen kan je hier timingsproblemen (= jitter) krijgen, maar dat is dus niet iets dat de CD zelf bevat.

Ja, precies zo heb ik het ook begrepen. Maar ik zal het artikel wat Remc aanhaalt een keer grondig doorlezen. Ik heb het al een keer gezien maar toen slechts cursorisch gelezen.

peter

[reMC]

- En wat draagt Bob aan als potentieele oplosing voor de leesproblemen: Een op PC-technologie gebaseerde oplossing...

Ja, maar dan houd je wel last van de jitter die al al op de cd zit en die bij de verschillende conversies plaats vindt, zoals Audiofiel ook aangaf.

[Don_Paul]

Nee, daar heb je dus geen last van. Er zit namelijk geen jitter op een CD, er zitten bits op een CD. Omdat je die niet perfect getimed kan uitlezen (mogelijk (hypothese) door de fysieke verschillen waarmee de bits op de CD zitten) ontstaat er jitter. En lees maar goed, ook Bob stelt dat dit door herbuffering op te lossen is.

En jitter onstaat ook nooit bij conversies die daarna weer gebufferd worden.

[)p(]

Ja, maar dan houd je wel last van de jitter die al al op de cd zit en die bij de verschillende conversies plaats vindt, zoals Audiofiel ook aangaf.

Kun je aangeven waar in de tekst je dat ziet staan. Ik lees slechts dat de jitter weer geintroduceerd wordt wanneer de klok weer wordt toegevoegd bijvoorbeeld wanneer de rip weer gebrand wordt op een cd. Dus weer geen verschillen in data maar "slechts" temporele verschillen tussen de bits.

"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."

Update: En hier kan dus ook jitter onstaan wanneer we de rip via de pc naar een dac sturen...vanuit de buffer moet de bitstream immers weer gecreeerd worden met behulp van een zo adequaat mogelijke klok.

peter

[Audiofiel]

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.

Zodra de CD an sich al als een prima computerbestand wordt gezien, houdt de hele discussie wat mij betreft op. Bitjes zijn bitjes: die computer-benadering gaat gewoon niet op voor een PCM-stream.

Ik denk dat het weinig nut heeft dat ik mij verder in deze discussie meng. Ik heb mijn ideeën erover gedeeld en laat het daar verder maar bij. Ik besteed mijn tijd liever aan nuttiger onderwerpen en vooral aan lekker luisteren.

[)p(]

Ik denk dat het weinig nut heeft dat ik mij verder in deze discussie meng. Ik heb mijn ideeën erover gedeeld en laat het daar verder maar bij. Ik besteed mijn tijd liever aan nuttiger onderwerpen en vooral aan lekker luisteren.

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

peter