N
nb
Gjest
Legg også merke til at saken fra BBC er fra 1974, eller 6 år før CD-formatet i det hele fantes. Når var det jitter ble standard buzzword i HiFi-kretser nå igjen?
Det er da irrelevant? Her skal det gripes etter de halmstrå som finnes kan.nb skrev:Legg også merke til at saken fra BBC er fra 1974, eller 6 år før CD-formatet i det hele fantes. Når var det jitter ble standard buzzword i HiFi-kretser nå igjen?
Jeg har pt. ikke klart å isolere «gåsehudfaktoren» til konkrete produkter/-sammenlikninger el. Jeg mener det er en helt generell sammenheng mellom forekomsten av gåsehud og «kvaliteten» på reproduksjonskjeden, men i bestemte tilfeller er det tilnærmet umulig å tilskrive den det ene, andre eller tredje - utskiftinger i utstyret, generell lyttestemning, humørvariasjoner, bad-ear-day, musikkvalg, variasjon i lytteteknikk og «progresjon», samt nær sagt alle mulige andre forhold og omstendigheter. En eller annen form for «rigorøs» lyttetestmetode er i så måte langt mer effektiv og treffsikkert mht konkrete variasjoner i lydkvalitet. Som regel så slentrer «gåsehudfaktoren» etter når de grunnleggende kvalitetene er på plass.CDWMcInSpots skrev:...
Dette er noe jeg også har lagt merke til og som volder meg bryderi.
Når man driver grundig evalueringslytting, f.eks. for å vurdere om man skal kjøpe en komponent, er det "rimelig greit" å få tak på objektive kriterier som f.eks. symbalutklinging og instrumentklang.
Det er derimot meget vanskelig å få tak på gåsehudfaktoren, enn si "måle" det emosjonelle utslaget. Hvis man sammenligner 2 komponenter, må det jo dessuten være repeterbart når man bytter til den andre komponenten, og tilbake igjen. Dette gjelder selv om resultatet bare skal benyttes av en selv.
...
Har noen andre av dere tanker om dette problemet eller forslag til (del)løsninger?
Dette er kanskje et tema som fortjener en egen tråd?
Du bruker selv PM for avspilling. Har du prøvd å sammenligne den samme filen i AIFF og FLAC via PM? Hvis du klarer å få disse til å høres like ut må du nesten forklare meg hvordan du gjør det. Jeg får det ikke til.vredensgnag skrev:Til tross for at man kan pakke, wrappe, pakke opp og konvertere disse filene innbyrdes, og så teste dem mot hverandre slik at man kan stadfeste at ikke så mye som en bit er blitt borte eller feilplassert på veien, så kjenner mange en uro over filer som ikke er i full størrelse.
Hvis dette er tilfelle så er prosessering bra! AIFF-filer spiller langt bedre enn FLAC hos meg. Selv har jeg ikke særlig tro på at det er slik det henger sammen.Som marsboer påpeker kan det godt være prosesseringen av den større filen som har medført en endring i lydsum; snarere enn utpakkingen av den komprimerte. Men det er ikke i tråd med "mest er best."
I en statisk tilstand er dette helt sikkert riktig, men signalet kommer jo fra et sted og skal videre. Dette "digital domain" er egentlig ganske flytende.vredensgnag skrev:"Whilst the signal is in the digital domain, the sample period is just a number, and as such has no jitter. It is impossible, therefore, for Sampling Jitter to be generated by any lossless CD ripping process."
Yup, den konverterer WAV til FLAC on-the-fly før den streamer filen som FLAC.[11-02-15 12:37:56.8024] Slim:layer:rotocols::File:pen (95) Opening file /media/Music/Radka Toneff/Butterfly WAV/Radka Toneff - 03 - Antonio's Song.wav
[11-02-15 12:37:56.8042] Slim:layer:rotocols::File:pen (178) Seeking in 0 into /media/Music/Radka Toneff/Butterfly WAV/Radka Toneff - 03 - Antonio's Song.wav
[11-02-15 12:37:56.8055] Slim:layer::Song:pen (476) URL is a song (audio): file:///media/Music/Radka%20Toneff/Butterfly%20WAV/Radka%20Toneff%20-%2003%20-%20Antonio%27s%20Song.wav, type=wav
[11-02-15 12:37:56.8069] Slim:layer::Song:pen (552) Tokenized command "/usr/share/squeezeboxserver/Bin/i386-linux/sox" -q -t wav "-" -t flac -C 0 -
Logikken ser ut til å være at den velger det første formatet som ikke er "disabled".[11-02-15 12:46:56.3171] Slim:layer::Song:pen (362) file:///media/Music/Radka%20Toneff/Butterfly%20WAV/Radka%20Toneff%20-%2003%20-%20Antonio%27s%20Song.wav
[11-02-15 12:46:56.3198] Slim:layer::TranscodingHelper::getConvertCommand2 (424) Matched: wav->pcm via: -
[11-02-15 12:46:56.3206] Slim:layer::Song:pen (386) seek=false time=0 canSeek=1
[11-02-15 12:46:56.3224] Slim:layer::TranscodingHelper::getConvertCommand2 (424) Matched: wav->pcm via: -
[11-02-15 12:46:56.3232] Slim:layer::Song:pen (407) Transcoder: streamMode=I, streamformat=pcm
[11-02-15 12:46:56.3241] Slim:layer::Song:pen (455) Opening stream (no direct streaming) using Slim:layer:rotocols::File [file:///media/Music/Radka%20Toneff/Butterfly%20WAV/Radka%20Toneff%20-%2003%20-%20Antonio%27s%20Song.wav]
[11-02-15 12:46:56.3257] Slim:layer:rotocols::File:pen (78) duration: [256.826] size: [45304224] endian [] offset: [44] for file:///media/Music/Radka%20Toneff/Butterfly%20WAV/Radka%20Toneff%20-%2003%20-%20Antonio%27s%20Song.wav
[11-02-15 12:46:56.3264] Slim:layer:rotocols::File:pen (95) Opening file /media/Music/Radka Toneff/Butterfly WAV/Radka Toneff - 03 - Antonio's Song.wav
[11-02-15 12:46:56.3279] Slim:layer:rotocols::File:pen (178) Seeking in 44 into /media/Music/Radka Toneff/Butterfly WAV/Radka Toneff - 03 - Antonio's Song.wav
[11-02-15 12:46:56.3291] Slim:layer::Song:pen (476) URL is a song (audio): file:///media/Music/Radka%20Toneff/Butterfly%20WAV/Radka%20Toneff%20-%2003%20-%20Antonio%27s%20Song.wav, type=wav
[11-02-15 12:46:56.3517] Slim:layer::StreamingController::_Stream (1228) 00:04:20:10:10:ad: stream
[11-02-15 12:46:56.3669] Slim:layer::Transporter::setDigitalInput (194) Switching to digital input 0
[11-02-15 12:46:56.3818] Slim:layer::StreamingController::_Stream (1263) Song queue is now 2
[11-02-15 12:46:56.3828] Slim:layer::StreamingController::_setPlayingState (2244) new playing state BUFFERING
[11-02-15 12:46:56.3838] Slim:layer::StreamingController::_setStreamingState (2257) new streaming state STREAMING
[11-02-15 12:46:57.2510] Slim:layer::StreamingController:layerTrackStarted (2056) 00:04:20:10:10:ad
[11-02-15 12:46:57.2519] Slim:layer::StreamingController::_setPlayingState (2244) new playing state PLAYING
[11-02-15 12:46:57.2527] Slim:layer::StreamingController::_Playing (361) Song 2 has now started playing
[11-02-15 12:46:57.2545] Slim:layer::StreamingController::_Playing (389) Song queue is now 2
[11-02-15 12:46:57.5621] Slim:layer::TranscodingHelper::getConvertCommand2 (424) Matched: wav->pcm via: -
Dette gir mening som out-of-the-box oppsett for å få mer stabil playback av WAV-filer over litt småshabby trådløse nett.nb skrev:Nok satt opp slik for å kutte båndbreddebehovet til nesten det halve.
We have done extensive measurements on power supply disturbance recently, and have compared results for both FLAC and WAV streaming. Our findings are as follows :
1. If we measure the power rail that feeds the main processor in the DS we can clearly see identifiable disturbance patterns due to audio decoding and network activity. These patterns do look different for WAV and FLAC - WAV shows more clearly defined peaks due to regular network activity and processing, while FLAC shows more broadband disturbance due to increased (but more random) processor activity.
2. If we measure the power rails that feed the audio clock and the DAC we see no evidence of any processor related disturbances. There is no measurable difference (down to a noise floor measured in micro-volts) between FLAC and WAV in any of the audio power rails.
3. Highly accurate measurements of clock jitter and audio distortion/noise also show no difference between WAV and FLAC.
The extensive filtering, multi-layered regulation, and careful circuit layout in the DS ensure that there is in excess of 60dB of attenuation across the audio band between the main digital supply, and the supplies that feed the DAC and the audio clock. Further, the audio components themselves add an additional degree of attenuation between their power supply and their output. Direct and indirect measurements confirm that there is no detectable interaction between processor load and audio performance.
One thing that isn't mentioned is internal screening around the board itself. On the KDS this is taken very seriously with internal areas milled into the casing for the processor / audio / psu sections, unlike the ADS / MDS. So there is still the issues of radiated noise from various components affecting others.
Squeezebox Server konverterer WAV til FLAC før streaming over nettverket, ja, og så pakkes det ut igjen lokalt på Squeezebox'en, enten det er en Touch eller noe annet. For å endre, finn de innstillingene jeg nevnte i innlegget jeg siterer nedenfor (i Server Settings->Advanced->File Types) og sett "Disabled" i stedet for "sox" i første rad for filformatet WAV og la det fortsatt stå "native" for PCM. Da streamer den PCM i stedet.musicman skrev:Noen som kan bekrefte om squeezebox touch automatisk konverterer wav til flac ved avspilling fra harddisk ? Har rippet en masse cd`er i wav , og lurer på hvordan dette stiller seg. Hvis den konverterer wav filer er vel dette bare med på å stresse skvisboksen unødvendig,,eller ?
Men jeg kan ikke si at jeg hører forskjell på WAV og FLAC hos meg, hverken "ekte" WAV streamet som PCM, WAV-fil konvertert og streamet som FLAC, eller FLAC-fil streamet som FLAC. Hvis det er noen som helst forskjell, er den veldig, veldig liten på min Transporter.Asbjørn skrev:Hmmm. Jeg konverterte alle sporene på en plate fra FLAC til WAV for å teste dette selv. Squeezebox Server er satt opp med fabrikkinnstillinger fordi jeg hittil har alt i FLAC, dvs:
File format Stream format Decoder
FLAC FLAC Native
MP3 Disabled
PCM flac
WAV FLAC sox
MP3 Disabled
PCM Native
Betyr det at SqueezeServer som default bruker sox til å konvertere WAV-filer til FLAC før den streamer dem til Transporteren?
Ja, det betyr noe. Ditt scenario er dermed forskjellig fra Asbjørns.musicman skrev:Glemte å si at jeg henter musikken fra ekstern harddisk via usb kabel inn i squeeze touch. Hvis dette skulle bety noe da.
Den påstanden gir lite mening. All den tid digitale data ikke er under konvertering så er de nettopp det - data. Og såfremt data ikke mistes, gir jitter som begrep ingen mening i en rent digital kontekst.ayaboh skrev:I en statisk tilstand er dette helt sikkert riktig, men signalet kommer jo fra et sted og skal videre. Dette "digital domain" er egentlig ganske flytende.vredensgnag skrev:"Whilst the signal is in the digital domain, the sample period is just a number, and as such has no jitter. It is impossible, therefore, for Sampling Jitter to be generated by any lossless CD ripping process."
Kanskje dette med fordel bør flyttes til Squeezebox-tråden?musicman skrev:TakkerCDWMcInSpots skrev:Ja, det betyr noe. Ditt scenario er dermed forskjellig fra Asbjørns.musicman skrev:Glemte å si at jeg henter musikken fra ekstern harddisk via usb kabel inn i squeeze touch. Hvis dette skulle bety noe da.
Asbjørn har: Datamaskin med disk og Squeezebox Server -> nettverk -> Logitech/Slim Devices Transporter
Du har: USB-disk -> Logitech Squeezebox Touch som kjører en egen "tiny" Squeezebox Server og en liten Linux (operativsystem)
Det Asbjørn konfigurerer på datamaskinen, må du evt. konfigurere på Squeezebox Touch. Hvor mye av dette som er (lett) tilgjengelig via det grafiske brukergrensesnittet på Squeezebox Touch, og hvor mye som bare kan nås ved innlogging via SSH, vet jeg ikke.
SSH: http://no.wikipedia.org/wiki/Secure_Shell
Linux: http://no.wikipedia.org/wiki/Linux
Tillegg:
Squeezebox Dueten din kjører antagelig i et scenario som ligner på Asbjørns:
Datamaskin med disk og Squeezebox Server -> nettverk -> Logitech Squeezebox Duet
Vil oppklare ett par ting; Jeg har Squeezebox server installert på pc . I tillegg bruker jeg en ekstern HD som står oppe ved anlegget i 2 etg. Dette fordi jeg ønsker å kunne spille uten å måtte ha pc på til enhver tid. Har sammenlignet disse to løsningene lydmessig, og greier ikke høre forskjell sålangt. Pc står i 1 etg. og Squeeze touch i 2 etg. Dette er kablet fra router og PC. Funker også med trådløst, men magefølelsen er bedre med kabel på plass.
Det som jeg hittil ikke har greid å få til er å spille av hi-rez 24/96, via den eksterne HD som står oppe ved anlegget. Kan det være at den serveren som er i "touch" ikke takler dette ? Hi-rez går greit via PC.
Takknemlig for innspill
mvh
Det stemmer. I en statisk tilstand er musikk kun data uansett hvordan den er lagret.I_L skrev:Den påstanden gir lite mening. All den tid digitale data ikke er under konvertering så er de nettopp det - data. Og såfremt data ikke mistes, gir jitter som begrep ingen mening i en rent digital kontekst.ayaboh skrev:I en statisk tilstand er dette helt sikkert riktig, men signalet kommer jo fra et sted og skal videre. Dette "digital domain" er egentlig ganske flytende.vredensgnag skrev:"Whilst the signal is in the digital domain, the sample period is just a number, and as such has no jitter. It is impossible, therefore, for Sampling Jitter to be generated by any lossless CD ripping process."
Nah. Kun ved konvertering til analog. Eller så vet du noe vi andre ikke vet..ayaboh skrev:Så fort man prøver å lese eller skrive til en disk, vil jitter være et problem, - lossless eller ei.
Jitter i den forstand som brukes her - jo.ayaboh skrev:Man behøver ikke å konvertere musikkdata for å få jitter.
Nei....men lesing eller skriving av disse dataene medfører jitter.
Pit-jitter er ujevnheter i CD-platens fysiske datamønster som brent eller stanset i platen, som kan føre til datafeil hvis det er for mye av den. Pit-jitter er et kvalitetsmål for en CDR-plate (eller brenning) og sier noe om sannsynligheten for datatap. En CD-brenner eller platebatch med høy pit-jitter vil ha flere plater med feil. Dette har ingenting å gjøre med klokkejitter som kan gi forvrenging under konvertering (og kun under konvertering).Ref JVC XRCD-prosess vedr. pit-jitter.
Påstanden er riktig den, pit-jitter og samplingsjitter er to vidt forskjellige ting. Det eneste som overføres/lagres når du ripper en CD er data, null informasjon om klokking eksisterer.Det jeg kommenterte var dette: " It is impossible, therefore, for Sampling Jitter to be generated by any lossless CD ripping process".
Feil.Så fort man prøver å lese eller skrive til en disk, vil jitter være et problem, - lossless eller ei.
Hysj, ellers kommer en audio editon av notepad.I_L skrev:Det kan åpnes i en teksteditor.
Lesing og skriving av CD/CD-ROM, ikke HD. Hvis dette er et problem med proff produksjonsutstyr, er det det sikkert med en vanlig CD-brenner også.I_L skrev:Feil.Så fort man prøver å lese eller skrive til en disk, vil jitter være et problem, - lossless eller ei.
Produksjon av en CD gir pit-jitter iflg dem som vet noe om dette. Mindre pit-jitter skal også være en av grunnene til at JVC XRCD'er har bedre lyd enn andre.Man skrev:Nah. Kun ved konvertering til analog. Eller så vet du noe vi andre ikke vet..ayaboh skrev:Så fort man prøver å lese eller skrive til en disk, vil jitter være et problem, - lossless eller ei.
Next to poorly designed digital recording equipment and poorly designed master Word Clocks, cables, equipment interconnection and improper termination are the most common causes of timing errors because they are a direct cause of jitter. [Julian Dunn]
Jeg vet da det, men det har ingen relevans her. Pit-jitter er et mål for feilraten til CD-plater, datafeil, mislykkede brenninger, det har absolutt ingenting med samplingsjitter å gjøre. Samplingsjitter/klokkejitter kan føre til forvrenging under AD- og DA-konvertering og er det som i hifi-sammenheng omtales som bare "jitter", men det har ingenting med pit-jitter å gjøre. Klokkesignalet genereres under AD- og DA-konvertering, av egen hardware, det blir ikke lagret på CDen eller kopiert under brenning eller noe.ayaboh skrev:Produksjon av en CD gir pit-jitter iflg dem som vet noe om dette.
Nei, pit-jitter har ikke noe med timing å gjøre, ingen timinginformasjon lagres i en musikkfil. Hvis de platene har mindre pit-jitter betyr det bare at de har høyere yield, dvs at de feiler mer sjelden.ayaboh skrev:Mindre pit-jitter skal også være en av grunnene til at JVC XRCD'er har bedre lyd enn andre.
Da snakker du om klokkejitter igjen; klokkesignalet må overføres mellom transport og DAC så de ikke skal miste sync. Det er to vidt forskjellige ting som ikke har noe med hverandre å gjøre.Digitalkabler mellom transport og DAC skal visst også være opphav til jitter iflg det jeg leser.
Min utheving. Jitter i lydsammenheng = timing errors. Timing er kun relevant under AD- og DA-konvertering, det eksisterer ikke noe timing så lenge data kopieres/behandles digitalt.Next to poorly designed digital recording equipment and poorly designed master Word Clocks, cables, equipment interconnection and improper termination are the most common causes of timing errors because they are a direct cause of jitter. [Julian Dunn]
I_L skrev:Da snakker du om klokkejitter igjen; klokkesignalet må overføres mellom transport og DAC så de ikke skal miste sync. Det er to vidt forskjellige ting som ikke har noe med hverandre å gjøre.
The only one that really matters is sampling jitter, deviations in the sampling interval, which will directly translate to distortion in AD or DA conversion.However, we also define clock jitter, which is jitter on the clock generation circuits in the system, as well as interface jitter which is jitter introduced in the transmission of digital signals. CD discs even have physical jitter, often referred to as landscape-jitter and pit-jitter. All these are secondary distortion sources; they can lead to sampling jitter, which will again lead to distortion. Good jitter rejection performance is thus a critical part of high-performance data converter design... [Ivar Løkken tror jeg]
Som sagt, det irriterer meg at dokumentet fortsatt sirkulerer, det er ikke jeg som sprer det for å si det sånn. Gamle datafiler hvis innhold man ikke kan gå god for som sirkulerer på nettet - sånn sett er vel jeg og Paris Hilton litt i samme båt her. Bitte litt.vredensgnag skrev:I_L skal ha for tålmodighet - men skal også ha på pukkelen for å spre uriktigheter!
;D
I praktiske audiosammenhenger er jeg enig i at anno 2011 er jittter et ikke-problem. Og det har vel også kanskje noe å gjøre med at vi som lager datakonvertere nå faktisk har ganske god forståelse av hva jitter er og hvordan disse tingene henger sammen. Myter er imidlertid fryktelig tunge å bryte ned; som feks at det er drivverket som er viktig for jitter eller at det er noen fundamental forskjell på lesing fra CD og harddisk. La oss nå ikke dra inn pit-jitter oppå alt også, det ordet har omtrent like mye å gjøre med klokkejitter som "tredve" har å gjøre med trær.Dette med jitter er et skrømt, en irrelevant bøyg, såfremt det ikke er direkte konstruksjonsfeil i komponentene.