Onderstaande discussie komt van elders (http://www.htforum.nl/yabbse/index.php?topic=38101.msg569966#msg569966):
Citaat van: Ettepet op januari 26, 2006, 11:21:33
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. :)
Citaat van: beunky op januari 26, 2006, 19:16:39
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.
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
Citaat van: Ettepet op januari 26, 2006, 23:47:45
Onderstaande discussie komt van elders (http://www.htforum.nl/yabbse/index.php?topic=38101.msg569966#msg569966):
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.
Citaat van: Ettepet op januari 26, 2006, 23:48:14
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.
Citaat van: reMC op januari 27, 2006, 00:19:51
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. :P
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).
Citaat van: sandervg op januari 27, 2006, 11:43:06
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. ;)
CiteerDe 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. ;)
Citaat van: Audiofiel op januari 27, 2006, 10:41:02
Gemodificeerd of niet, zie mijn post hierboven. Je kunt toch onmogelijk door mindere hardware en twee extra omzet-stappen een beter resultaat bereiken. :P
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 :o
Citaat van: Audiofiel op januari 27, 2006, 10:37:10
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.
Citeer
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?
Citeer
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.
Citeer
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.
Citeer
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.
Citeer
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.
Citeer
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).
Citeer
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.
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.
Citaat van: Audiofiel op januari 27, 2006, 10:37:10
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
Citaat van: reMC op januari 27, 2006, 12:29:04
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.
Citaat van: Don_Paul op januari 27, 2006, 13:45:41
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 ;)
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?
Citaat van: Don_Paul op januari 27, 2006, 14:16:58
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.
Citaat van: reMC op januari 27, 2006, 13:51:04
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
Hier (http://www.digido.com/portal/pmodule_id=11/pmdmode=fullscreen/pageadder_page_id=52#anchor5397851) 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.
Citaat van: vpv op januari 27, 2006, 14:30:29
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.
Citaat van: reMC op januari 27, 2006, 14:34:01
Hier (http://www.digido.com/portal/pmodule_id=11/pmdmode=fullscreen/pageadder_page_id=52#anchor5397851) 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...
Citaat van: Don_Paul op januari 27, 2006, 14:37:22
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
Citaat van: Don_Paul op januari 27, 2006, 14:42:23
- 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.
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.
Citaat van: reMC op januari 27, 2006, 14:56:48
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
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. ;D
Citaat van: Audiofiel op januari 27, 2006, 15:12:03
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. ;D
Daar heb je helemaal gelijk in ;D Wat mij betreft kunnen we deze discussie hiermee dan ook afronden 8)
peter
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 ;)
Citaat van: vpv op januari 27, 2006, 15:15:00
Daar heb je helemaal gelijk in ;D Wat mij betreft kunnen we deze discussie hiermee dan ook afronden 8)
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.
Citaat van: Audiofiel op januari 27, 2006, 10:37:10
......... 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.
Citaat van: Don_Paul op januari 27, 2006, 12:24:10
................
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?
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.
Citaat van: Audiofiel op januari 27, 2006, 15:12:03
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 :)).
Citaat van: FrenkB op januari 27, 2006, 15:27:49
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.
Citaat van: Don_Paul op januari 27, 2006, 15:35:51
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?
Citaat van: reMC op januari 27, 2006, 15:15:35
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.
Citeer
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.
Citaat van: reMC op januari 27, 2006, 15:38:04
Kan je de 'omzettingsfase' zoals jij die bedoelt wat beter definiëren? Zit het loopwerk daar bijvoorbeeld ook in?
Omzetting klinkt meer als DAC
Citaat van: Bas Janssen op januari 27, 2006, 15:24:36
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'
Paul, ik volg je niet helemaal. Je zegt in een reactie op mijn post
Citeer
Als je het over het PURE digitale domein hebt zit daar geen jitter in.
Vervolgens zeg je dit
Citeer
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.
Citaat van: Bas Janssen op januari 27, 2006, 15:43:17
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.
Citaat van: Don_Paul op januari 27, 2006, 15:42:49
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.
CiteerNee, 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.
Citaat van: Bas Janssen op januari 27, 2006, 15:43:17
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.
Citaat van: Don_Paul op januari 27, 2006, 15:46:32
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
Citaat van: FrenkB op januari 27, 2006, 15:49:17
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.
Citaat van: reMC op januari 27, 2006, 15:56:38
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...
Citeer
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.
Citeer
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.
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 :D
Citaat van: FrenkB op januari 27, 2006, 16:08:12
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 :D
Meestal zijn dat niet echt verschillende "soorten", maar eigenlijk meer verschillende "oorzaken" van temporele afwijkingen in de bitstream.
peter
Citaat van: FrenkB op januari 27, 2006, 16:08:12
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 :D
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.
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.
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. :(
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 ?
Citaat van: Dirkie op januari 28, 2006, 16:11:41
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
Dus hoeveel jitter er ook in een stream zit, zodra je er pc-data van maakt is die weg?
Citaat van: FrenkB op januari 28, 2006, 16:28:30
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
Maar er moet dan toch alsnog weer een omzetting plaatsvinden, waar opnieuw jitter aan te pas komt?
Citaat van: reMC op januari 28, 2006, 18:27:23
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.
Citaat van: FrenkB op januari 28, 2006, 19:05:40
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?
Citaat van: reMC op januari 28, 2006, 19:35:44
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.
Citaat van: FrenkB op januari 28, 2006, 19:37:43
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?
Maar die squeezebox creeert zelf ook weer jitter. Dus krijg je daar het probleem.
Citaat van: reMC op januari 28, 2006, 19:35:44
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
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.
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 :D
Citaat van: FrenkB op januari 29, 2006, 21:59:27
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... ;)
Citaat van: FrenkB op januari 29, 2006, 21:59:27
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 :D
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
Citaat van: FrenkB op januari 29, 2006, 21:59:27
Ieder loopwerk dat foutloos een cd kan uitlezen zou volgens die theorie volstaan. Klinkt te mooi om waar te zijn :D
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.
Citaat van: FrenkB op januari 29, 2006, 21:59:27
Ieder loopwerk dat foutloos een cd kan uitlezen zou volgens die theorie volstaan. Klinkt te mooi om waar te zijn :D
Dat loopwerk komt nooit ;)
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.
Citaat van: Don_Paul op januari 30, 2006, 22:39:58
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
Citaat van: Don_Paul op januari 30, 2006, 22:39:58
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.
Citaat van: Don_Paul op januari 30, 2006, 22:39:58
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?
Citaat van: FrenkB op januari 31, 2006, 08:58:51
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.
Citaat van: Tjeerd1 op januari 31, 2006, 12:03:31
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...
Citaat van: Don_Paul op januari 31, 2006, 13:26:26
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 ???
Citaat van: Don_Paul op januari 29, 2006, 21:56:23
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.
CiteerIn 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).
Citaat van: reMC op januari 31, 2006, 13:31:35
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? :)
Citeer
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.
Citeer
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.
Citeer
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/ (http://www.cdrfaq.org/)
Hier staat redelijk goed beschreven op welke wijze de CD-data nu exact wordt vastgelegd.