Jplay

[Gość StaryM]

Widze ze sie w koncu przekonales do JPLAY-a i go zamierzasz kupic ;) a tyle marudziles tu :D

No widzisz wyszlo szydlo z worka :D

 

Nie sądzę, żeby to tak można było interpretować. Ja w każdym razie takiego kota w worku bym nie kupił. To jest raczej argument, by się od takiego programu trzymać z daleka.

[Gość SlawekR]

Widze ze sie w koncu przekonales do JPLAY-a i go zamierzasz kupic ;) a tyle marudziles tu :D

No widzisz wyszlo szydlo z worka :D

 

Jasne, jasne, tak sobie to tłumacz :-))). Możesz być pewien na 500%, że niezależnie jak by ten program mógł być potencjalnie świetny, to go bez umowy licencyjnej nie kupię. Taka opcja jest absolutnie wykluczona, gdyż szanuję swoje pieniądze i nie będę ich wyrzucać w ciemno.

 

A osobiscie Ci powiem ze bez EUL-i tez sie dobrze slucha ;)

 

Do czasu, aż się coś nie spier.. znaczy zepsuje w systemie z powodu działania aplikacji i trzeba będzie ustalić zakres odpowiedzialności producenta programu i użytkownika. Albo gdy producent, albo inny podmiot, zarzuci użytkownikowi złamanie zasad licencji na użytkowanie aplikacji.

 

Ewentualnie gdy producent zadeklaruje "na gębę" dożywotnie aktualizacje i ktoś kierując się tą przesłanką dokona zakupu, po czym nagle producent wprowadzi jednak EULĘ, gdzie nie będzie mowy o darmowych aktualizacjach, albo wręcz będzie mowa o licencji czasowo wygasającej. Jak nie ma umowy licencyjne, to jest wolna amerykanka. Dla mnie sprawa jest prosta, jest program, musi być umowa licencyjna na jego użytkowanie. Wszystko to stanie się dla Ciebie jasne i istotne, jak uświadomisz sobie i zakodujesz w głowie, że w przypadku oprogramowania nie kupujesz programu jako wartości samej w sobie, a zawsze kupujesz licencję na jego użytkowanie, czy to dożywotnią, czy czasową, ale wyłącznie licencję na użytkowanie.

 

Albo inaczej, bardziej obrazowy przykład:

 

Kupiłeś licencję na Jplaya, wydałeś 100 euro, w końcu jest to trochę grosza. Z jakiegoś względu chcesz go odsprzedać, ba... podarować w prezencie, dajmy na to, Sławkowi. Wolno Ci to zrobić, czy nie wolno? Musisz go sprzedać razem z komputerem, na którym pierwotnie zainstalowałeś aplikację, czy możesz ją odinstalować i odsprzedać luzem? Licencja jest przypisana do opakowania (box), do sprzętu, do użytkownika, do grupy użytkowników, gospodarstwa domowego? To wszystko reguluje EULA. A jak jej nie ma, to mamy wolną amerykankę.

 

Z góry uprzedzam, że argument, że przecież można zapytać producenta mailem nie przejdzie, bo jeśli ktoś takiego argumentu użyje, to odpowiem ok, ale ja też zapłacę mailem, zeskanuję kasę i tak zapłacę ;-).

 

Nie sądzę, żeby to tak można było interpretować. Ja w każdym razie takiego kota w worku bym nie kupił. To jest raczej argument, by się od takiego programu trzymać z daleka.

 

Otóż to. Bo bez EULI jest to zakup totalnie audiofilskiego powietrza. EULA reguluje formę w jakiej otrzymujemy potwierdzenie posiadania praw do użytkowania konkretnej aplikacji, czy ma to być klucz licencyjny, czy certyfikat, czy jeszcze jakaś inan forma. A bez EULI to kupujemy powietrze i na potwierdzenie również mamy powietrze.

[arczi87]

Tak sobie myślę, że producent wyczuje (w końcu) potrzebę EULI. No i wprowadzi ten UPgrejd :D i nasz kochany Jplay będzie kosztował 200 Euro. Przecież to nie będzie byle jaki upgrade i ktoś to napisać musi :).

[prezi]

Ja slucham bez hibernacji zazwyczaj wazne aby silnik byl xtreme i bufor z mala iloscia probek no i by byl kernel streaming. Naprawde duze roznice w dzialaniu JPLAYa wychodza dopiero na dobrych sprzetach ale u Ciebie tez musi byc slychac. Z hibernacja jest duzo lepiej tak na marginesie

 

Pozdrawiam Stasiop

 

 

Juz pisalem ze pomiary jitteru sa wyjatkowo kosztowne i nie wiem czy w Polsce ma ktos jedno takie urzadzenie ktorym szlo by to zmierzyc i na takich poziomach. Jedynym rozsadnym rozwiazaniem jest sluchanie- wbrew pozorom nie jest to takie trudne i mozna nauczyc sie tego sluchac znacznie powyzej jakiejkolwiek sugestii, poniewaz jitter ma drastyczny wplyw na dzwiek. I tak przykladowo jesli zmieni sie kwarc czy tez generator i robi sie to w wielu urzadzeniach to juz sie wie jaki ma to wplyw na dzwiek. dodatkowo przeprowadza sie czesto podczas tunningu dodatkowe odtlumianie zasilan co powoduje zmniejszenie zaklocen na liniach a tym samym zmniejszenie jitteru - to tez wyraznie slychac. sa tez inne metody ekranowanie w.cz filtrowanie zasilan tlumienie drgan mechanicznych, prowadzenie mas odklocanie mas, zabawa z kondensatorami na w.cz. to wszystko wyraznie slychac nie ma z tym najmniejszego problemu :)

Nie mowiac juz o wplywie takie JPLAYera ktorego wplyw dla mnie i dla ludzi dysponujacym dobrym sprzetem jest sprawa oczywista!

Ja słucham ayranu i też mi gra duużo lepiej.

[zibra]

A ja mam pytanie - skoro nie ma wersji na Linuxa co to oznacza? Mam o 1/3 gorszy dzwiek czy Linux jest lepszy od Windowsa z JPlay?;)

Myslcie logicznie;)

[Gość SlawekR]

A ja mam pytanie - skoro nie ma wersji na Linuxa co to oznacza? Mam o 1/3 gorszy dzwiek czy Linux jest lepszy od Windowsa z JPlay?;)

Myslcie logicznie;)

 

No nie żartuj sobie, logika to jest zło, przed którym wielu dyskutujących ucieka. Jak próbowałem się nią posługiwać w dyskusji, to zaraz była ucieczka w bok. W możliwość logicznych rozważań nie chce mi się wierzyć. Ale ok, chcesz przykład, proszę bardzo:

 

System Windows bez udziału Jplaya, generuje dramatyczny syf, który powoduje że dźwięk bez tej cudownej aplikacji, jest gorszy o jedną trzecią, czyli o 33%. I to w trybie bez hibernacji. A skoro tryb hibernacji, przynosi kolejną poprawę, tu żebym nie był posądzony o manipulację, więc bez szaleństw, powiedzmy o 10%, czyli razem mamy:

 

Dźwięk z samego Windows, w związku z jego destrukcyjnym wpływem na sygnał, gorszy jest o 43%.

 

Dźwięk z Windows, z użyciem Jplaya, daje dramatyczną poprawę, o rzeczone 43%.

 

Logiczny wniosek -> system Windows, bez udziału cudownego poprawiacza jittera, z racji na sam charakter działania, przy zwykłej operacji wysłania danych na wyjście, powoduje stratę na jakości o 43%.

 

Jedziemy dalej. Kolega Stasiop, przyznał się, że po zripowaniu płyty, dokonuje operacji matematycznych na danych odpowiadających sygnałowi audio, przekształcając sygnał 16bit 44,1kHz do 24bit 96kHz.

Należy zauważyć, że dokonuje tej operacji w tym samym destrukcyjnym systemie Windows. Mało tego wykonuje operację przekształcenia danych i to stratnego przekształcenia, bo raz nieodwracalnego, dwa w tym samym systemie, który z samej natury działania powoduje znaczną utratę jakości dźwięku, no bo przecież do tej czynności nie używa Jplaya, chyba że program "nabawił się" nowych opcji, o których nie słyszałem. Mało tego, Kolega twierdzi, że takie przekształcenie ma zbawienny wpływ na dźwięk, pomimo braku Jplaya czuwającego nad ograniczeniem syfu od systemu. A zwykłe asynchroniczne przesłanie danych na wyjście, również bez Jplaya, obarczone jest stratą jakości o skandalicznej wręcz wartości 43%.

 

A Kolega Zibra apeluje o użycie logiki w rozważaniach, dobre sobie... ;-))).

 

Tam gdzie jest Voodoo, tam nie ma miejsca na logikę. Voodoo kieruje się się swoją "wygodną" logiką. Tam gdzie mu pasuje, tam nie ma wpływu systemu, ba jest poprawa od czynności wykonywanych w określonym środowisku. A tam gdzie nie pasuje, tam prosta czynność przesłania danych, niszczy dźwięk w druzgocący sposób, w tym samym systemie i środowisku. Bo inaczej nie można nazwać 43% gorszego dźwięku, jak druzgocącym niszczeniem.

 

Logiki się zachciało.... dowcip stulecia :-).

[Gość StaryM]

Logiki się zachciało.... dowcip stulecia :-).

Dziękuję. Dawno nie czytałem lepszego tekstu.

[Gość SlawekR]

No ale dokładnie do tego to się sprowadza, jeśli zastosować proste logiczne rozumowanie.

 

Logika jplayowa Kolegi Stasiop jest taka, że program ten buforuje dane w pamięci, stosując określoną zbawienną metodę przeplotu danych w pamięci, patrz silnik extreme. Dzięki temu następuje lepsze zegarowanie danych i odcięcie się od jakości nośnika, który wedle Kolegi ma znaczenie zasadnicze, choćby wspomniany przez niego odczyt z pendrive, różny od warunków, na przykład tego czy pamięć flash została sformatowana przed momentem. To jest logika jplayowa, która ma znaczenie tym większe, że Kolega traktuje odczyt danych audio, jak odczyt takich samych danych ze źródła tradycyjnego.

 

Tyle, że mamy tutaj mały problem, bo czymże jest pobranie tych samych danych, w tym samym komputerze, z tym samym zasilaczem, procesorem, pamięciami itd? Przecież to będzie w 100% identyczny odczyt danych, który w logice jplayowej należy traktować jako odczyt ze źródła, później mamy konwersję, a następnie powtórny zapis do źródła. A skoro nie uczestniczy w tym jplay ze swoimi algorytmami, to cała "shitowość" systemu, powodująca stratę tych kilkudziesięciu procent jakości dźwięku, cały ten syf, nie dość że wpłynie na dźwięk, to zostanie wkodowany w wynikowy zapis danych w postaci przekłamań. Dramat normalnie. To oczywiście jeśli uznać, że działa logika jplayowa. Więc cała operacja jest ostatecznie psu na budę, bo i tak mamy jeden ładny komplecik zakłóceń, tyle że już "wkompilowany" w dane zapisane na dysku. A jeśli uznać, że nic się złego nie dzieje podczas takiej konwersji, gdyż odbywa się na danych asynchronicznych, to i przestaje działać logika jplayowa i jesteśmy w punkcie wyjścia.

 

Nie dziwne więc, że jeśli ktoś chce stosować logikę jplayową, to musi uciekać jak najdalej od logiki normalnej, gdyż jego teorie nijak nie będą się kupy trzymać, logicznie patrząc :-).

 

Jakby się więc nie obrócić, zawsze będzie d..a z tyłu :-P.

 

Oczywiście Kolega można napisać, tak przynajmniej przypuszczam, że taką ma intencję konwersji do 96kHz, że i tak mamy zysk bo DAC dostając już 96kHz, nie wykona samodzielnie takiej konwersji, swoimi gorszymi algorytmami. Tyle, że jest jeden tyci problem znowu. Kolega Stasiop używa Sabre 9018, a on i tak dokona konwersji, tyle że jako jeden z nielicznych DACów, zrobi to do ogromnej częstotliwości 1,5MHz. więc mu totalnie rybka, czy zrobi to z 44,1 czy z 96kHz. Wcześniejsza konwersja nic pozytywnego więc nie wniesie, a może tylko zepsuć, gdyż wali w łeb całą ideę bitperfektowości sygnału ze źródła do DACa.

[Gość StaryM]

Wcześniejsza konwersja nic pozytywnego więc nie wniesie, a może tylko zepsuć, gdyż wali w łeb całą ideę bitperfektowości sygnału ze źródła do DACa.

Mnie ta jego deklaracja najbardziej rozbawiła. :)

[Gość SlawekR]

Mnie ta jego deklaracja najbardziej rozbawiła. :)

 

No i informacja z ostatniej chwili, jak donosi recenzent ze strony 6moons, a na którą to recenzję zresztą zwraca uwagę Kolefa Stasiop. Otóż okazuje się, że postępując zgodnie z zaleceniemi autorów jplaya, zainstalował on Windows 8 i....... i uzyskano dalszą poprawę dźwięku. Podsumujmy, ile to już będzie? Znowu dodamy skromnie, żeby nie przeginać, tak z 10%. Po opisach "poprawy jakości", te 10% na pewno nie będzie przegięciem. Razem to będzie już, ile? 53% poprawy w jakości dźwięku i to bez ingerencji w dane, a "zwykłymi" zabiegami czary-mary hokus-pokus.

 

Tak sobie myślę, jak oni wszyscy byli w stanie słuchać muzyki z komputera, pisać recenzje przetworników i całej reszty związanej z komputerowym audio. Przecież tak ogromna różnica, to wcześniej dźwięk musiał być na poziomie radyjka w kuchni. Jak mogli to wszystko robić, bez odruchów wymiotnych, zanim powstał Jplay :-). Wszystkie wcześniejsze recenzje z tych serwisów, tak patrząc, to należałoby wyrzucić do kosza, gdyż powstawały na nieoptymalnym źródle. Tyle lat i tyle tekstów zmarnowane :-P

[Lumperator]

Dramat normalnie. To oczywiście jeśli uznać, że działa logika jplayowa. Więc cała operacja jest ostatecznie psu na budę, bo i tak mamy jeden ładny komplecik zakłóceń, tyle że już "wkompilowany" w dane zapisane na dysku.

Kiedyś znajomy zapytał mnie, czy jak przegra film z jednego dysku na drugi, to czy obraz będzie wyraźny. Wtedy nie przypuszczałem, ze to pytanie jest jak najbardziej poważne. ( :D )

[migrena]

Konwersja 44/16 na 96/24 ma zbawienny wplyw na jitter... W jakiz to sposob niby? I jak to zostalo sprawdzone?

 

PS

Jak sobie podkrece galke glosnosci o jeden "szczebelek" to tez wydaje mi sie, ze jest poprawa. Jak sie ma moja ingerencja w sygnal wzgledem software'owego oversamplingu pod katem slyszalnej poprawy jakosci? Takie podchwytliwe pytanie. :)

[Gość SlawekR]

Kiedyś znajomy zapytał mnie, czy jak przegra film z jednego dysku na drugi, to czy obraz będzie wyraźny. Wtedy nie przypuszczałem, ze to pytanie jest jak najbardziej poważne. ( :D )

 

Tyle, że tutaj mamy bardziej rażący przypadek. Nie chodzi nawet o kopiowanie, gdzie ktoś mógłby próbować wywodów, że kopiowanie to prosta czynność przeniesienia danych z jednego miejsca w drugie. Ale tutaj mamy do czynienia z aplikacją do konwersji danych, czyli nie ma mowy o prostym kopiowaniu. Na 100% jest odczyt danych ze źródła, konwersja w aplikacji i ponowny i zapis. Co oznacza, że odczyt ten, to identyczna czynność jak odczyt przed wysłaniem do konwertera asynchronicznego, która to czynność, jest jakoby w 30-40% degradująca jakość dźwięku, bez udziału Jplaya oczywiście.

 

Konwersja 44/16 na 96/24 ma zbawienny wplyw na jitter... W jakiz to sposob niby? I jak to zostalo sprawdzone?

 

Sądzę, co już wcześniej napisałem, że chodzi o zastąpienie, potencjalnie występującej, konwersji na poziomie przetwornika, taką bardziej kontrolowaną, wydajną i podobnież lepszą, wykonywaną na poziomie oprogramowania w komputerze. Tyle, że w przypadku Sabre taki zabieg nic nie daje, gdyż konwersja, tak czy inaczej, wystąpi na poziomie przetwornika i to do bardzo wysokiej częstotliwości. Zresztą z tego powodu, Sabre wymaga zegarów na poziomie 80-100MHz.

 

Wykonanie konwersji w komputerze, niby mocno kontrolowanej przez użytkownika, to jednak Kolega Stasiop nie uwzględnił zjawisk wynikających z logiki jplayowej, czyli pół tony zakłóceń i jittera, podczas nieuniknionej operacji odczytu danych ze źródła.

 

Zresztą osobiście uważam, że taka konwersja, to najgorsza krzywda jaką użytkownik może zrobić komputerowym danym audio. I kompletnie nic nie daje.To jest kompletne "fuj" do kwadratu. Bo "na pochyłe drzewo i Salomon nie naleje", czy jakoś podobnie to szło ;-P.

[Stasiop]

Najwieksze korzysci z resamplingu i ditherowania na 24/94k daja nagrania z poczatku ery cyfrowej. Powodem sa prymitywne przetworniki i zajitterowane przetwarzanie tej epoki.Ucho poprostu duzo bardziej woli wysoki szum ditheru anizeli szum starych zajitterowanych zegarow i petli PLL. Takie nagrania mozna calkiem mocno "naprawic" wiem bo porownywalem takie poprawione nagrania z nowymi produkcjami studyjnymi 24/96k. Poprawa idzie prawie w tym samym kierunku ale oczywiscie te studyjne z tasm matek graja znacznie lepiej. Ale i na plikach Hi-res przetwarzanie tez slychac bo nie jest to sluchane z Flaca ktory musi byc rozpakowywany (wiec szumi cyfrowo) dwa wieksza ilosc probek i przy szybszej transmisji przeslana przez konwerter tu przyznam (tak mi sie wydaje) powoduje mniejsze bledy czasowe (i ma to uzasadnienie naukowe zegary na wyzszych czestotliwosciach maja mniejsze jittery) trzy konwersja bez pre echa powoduje to ze ucho nie znosi pre echa i taki dzwiek jest bardziej naturalny - odpowiedz mozna znalezc w psychoakustyce. cztery dostosowanie pliku do osobistych upodoban brzmieniowych ;)

 

Pozdrawiam Stasiop

 

A wiecie ze slychac nawet rodzaje ripperow malo tego wplyw ma nawet predkosc zgrywania!!!

 

Paranoja do kwadratu no nie? ;)

 

Ale chyba juz mam na to teorie ;)

[Gość StaryM]

Jestem pod wrażeniem.

Mam trochę starych filmów na VHS zgranych do postaci cyfrowej. Kiepskie są, bo tylko 640x480. Zapewne nie będzie dla ciebie żadnym problemem, by opracować sposób na łatwe przerobienie ich na format Full HD 1920x1080 z pogłębieniem kolorów i wydobyciem tych zagubionych w procesie cyfryzacji pierwotnej szczegółów.

[PPM]

A wiecie ze slychac nawet rodzaje ripperow malo tego wplyw ma nawet predkosc zgrywania!!!

 

Czytam ten wątek od początku istnienia i dopiero te zdanie zmusiło mnie do zabrania głosu.

Jak z wykształcenia informatyk, muszę w tym momencie zaprotestować, gdy ktoś szerzy głupoty. Jeżeli dwa pliki po ripie są bitowo identycznie to nie ma takiej opcji, żeby brzmiały inaczej. Nie przyjmując takiego założenia można dojść do np. takich wniosków:

- zdjęcia przegrane z aparatu za pośrednictwem kabla bezpośrednio z aparatu będą bardziej kolorowe niż te które przegramy z czytnika kart (bo te przez czytnik będą zczytane z wiekszą prędkością)

- albo bliżej tego forum co już ktoś kiedyś napisał, stukrotne przegranie pliku z cyfrowo zapisanym dźwiękiem za pomocą różnych mediów (wifi, mail, czy co tam innego) zmieni jego brzmienie, bo przecież nie zawartość pliku

 

Można też pójść dalej w tej abstrakcji i np. zlecić twórcowi JPlay'a napisanie programu do kopiowania plików muzycznych, oczywiście przez ten cudowny engine, w celu poprawy ich sygnatury dźwiękowej.

 

Celowo nie wypowiadam się na temat brzmienia JPlay bo go nie testowałem.

[Stasiop]

Czytam ten wątek od początku istnienia i dopiero te zdanie zmusiło mnie do zabrania głosu.

Jak z wykształcenia informatyk, muszę w tym momencie zaprotestować, gdy ktoś szerzy głupoty. Jeżeli dwa pliki po ripie są bitowo identycznie to nie ma takiej opcji, żeby brzmiały inaczej. Nie przyjmując takiego założenia można dojść do np. takich wniosków:

- zdjęcia przegrane z aparatu za pośrednictwem kabla bezpośrednio z aparatu będą bardziej kolorowe niż te które przegramy z czytnika kart (bo te przez czytnik będą zczytane z wiekszą prędkością)

- albo bliżej tego forum co już ktoś kiedyś napisał, stukrotne przegranie pliku z cyfrowo zapisanym dźwiękiem za pomocą różnych mediów (wifi, mail, czy co tam innego) zmieni jego brzmienie, bo przecież nie zawartość pliku

 

Rozumiem Cie doskonale :)))) ja jak sie o tym dowiedzialem to bylem mocno sfrustrowany bo nie miescilo mi sie to w glowie ze rippery moze byc slychav jak i predkosci zgrywania a z zawodu tez jestem informatykiem ;)

 

Ale...niestety jest taka mozliwosci teoretyczna. Ale to wyjasnie innym razem, jaka mam na to teorie, bo temat komplikuje sie do 10 potegi ;)

 

A jesli chodzi o roznice w brzmieniu 100 kopii to istnieje taka mozliwosci oczywiscie plik bitowo bedzie nawet na milionowej kopii logicznie spojny ale czasowo juz nie bo tak naprawde nagrywany bedzie na analogowym nosniku.

 

 

Ale w skrocie moge tylko powiedziec ze najprowdopodnie chodzi tu o kumulacje bledow czasowych na dysku twardym.

 

I nie wyzywaj mnie od glupcow ze szerze glupoty bo sam tematu do konca nie zglebiles wiec zawsze warto zachowac ostroznosc a nie wypowiadac sie autorytarnie i ostatecznie - no chyba ze jestes na 100% pewien

 

Pozdrawiam StasioP

[PPM]

Szerzenie głupot nie jest jednoznaczne z byciem głupcem - z tym chyba możesz się zgodzić. Zdarza się każdemu (szerzenie głupot), mi także.

 

Dobrze, idąc Twoim tropem, kumulacja błędów czasowych na dyskach twardych, będących wiodącym typem nośników danych w dzisiejszym świecie, nieuchronnie zbliżałoby świat do katastrofy, poprzez losowo ale jak twierdzisz PEWNIE pojawiające się błędy. Ja jakoś nie zauważyłem błędów w plikach tekstowych czy graficznych, czy jakichkolwiek innych, a niektóre posiadam od ok. 20 lat i przegrywałem je wielokrotnie począwszy od Amigi przez PC, poprzez dyskietki, CD, pendrive, wifi.

 

Z Atari plików już nie mam. Ale tam nie było dysków twardych :) Ale też jestem pewien, że dobrze przegrane pliki nie zawierałyby błędów.

 

Nie rozumiem, czemu ten problem miałby dotyczyć JEDYNIE plików z muzyką.

[Stasiop]

Ja jakoś nie zauważyłem błędów w plikach tekstowych czy graficznych, czy jakichkolwiek innych, a niektóre posiadam od ok. 20 lat

 

Ale co Ty tym zdaniem chcesz zaprzeczyc ze jitter nie wplywa na przetwarzanie C/A?

 

Problem ujawnia sie dopiero przy przejsciu na swiat analogowy. problemem jest przetwarzanie C/A bo ono musi miec super dokladne przedzialy czasowe aby sygnal byl przetworzony wiernie. Sorki ale nie chce mi wkolko tlumaczyc jakie znieksztalcenia w sygnale analogowym powoduje jitter i jaki jest tego mechanizm.

A jesli chodzi o fotografie nie znam sie na tym ale ponoc specom od tego juz wiadomo ze takie cos wystepuje i minimalizuja to w przetwornikach

 

Nie rozumiem, czemu ten problem miałby dotyczyć JEDYNIE plików z muzyką.

Nie one dotycza wszystkich problemow gdzie nastepuje przejscie z cyfry na analog tylko technika to w zaleznosci jak to jest skonstruowane zwielokratnia. A ucho jest chyba dziwnym organem ze slyszy takie niuanse sam sie nad tym czesto zastanawiam...Mysle ze jest to kwestia ewolucji ze w przyrodzie nigdy nie bylo takich efektow jak jitter wiec mozg to interpretuje jako cos bardzo innego od tego co nauczyla mozg ewolucja

[nedj]

Można też pójść dalej w tej abstrakcji i np. zlecić twórcowi JPlay'a napisanie programu do kopiowania plików muzycznych, oczywiście przez ten cudowny engine, w celu poprawy ich sygnatury dźwiękowej.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) poruszyłem już problem kopiowania (nie ripowania) danych muzycznych:

 

Jak wiadomo, programy zgrywające mają bardzo duży wpływ na jakość dźwięku, podobnie zresztą jak odtwarzacze programowe.

A co z programami do zarządzania danymi? Czy one przypadkiem też nie ingerują w dźwięk? Czy plik skopiowany/przeniesiony za pomocą Exploratora będzie grał tak samo, jak po użyciu np. Total Commandera? Jaka metoda obsługi będzie brzmieniowo lepsza: przeciąganie myszą czy może jednak F5/F6 (w przypadku TC) i Ctrl+C/Ctrl+X/Ctrl+V (w przypadku Exploratora)? Czy w ramach jednego HDD i jednej partycji lepiej przenosić czy kopiować pliki? Ta druga opcja na chłopski rozum powinna być lepsza, pozwala bowiem na spokojne i dokładne odczytanie poszarpanego pliku i poprawione zapisanie go w innym obszarze dysku, co nawiązuje do metody stosowanej i polecanej przez [email protected] w przypadku płyt CD. Może także tutaj uda się zmniejszyć jitter i w ten sposób pozbyć się cyfrowego nalotu nagrań.

Wtedy mnie wyśmiano i nikt merytorycznie nie podjął tematu.

 

Nie rozumiem, czemu ten problem miałby dotyczyć JEDYNIE plików z muzyką.

Bo audiofile to najbardziej nieszczęśliwa gruba hobbystów na świecie i swego rodzaju naród wybrany.

Tylko w przypadku tego hobby nic nie działa, wszystko wpływa na wszystko, najmniejsze problemy powodują ogromne skutki itd.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[Stasiop]

Tylko w przypadku tego hobby nic nie działa, wszystko wpływa na wszystko, najmniejsze problemy powodują ogromne skutki itd.

Hehehehe dobre usmialem sie :) :D

 

Ale odpowiedzia jest na to wlasnie ewolucja trzeba to sobie dokladnie przemyslec...Odpowiedzia na to, ze ucho, a wlasciwie mozg, ktory jest czuly na cos czego w naturze nigdy nie bylo. Bo technika przeciez generuje cos tzn znieksztalcenia ktorych nigdy w przyrodzie nie bylo!

 

TUTAJ poruszyłem już problem kopiowania (nie ripowania) danych muzycznych:

Czytam ten watek rozumiem powage problemu ale dobrze mozna sie tam usmiac, jak widac audiofile to nie sa smutasy np wlasna olejarnia do dobrego lozyskowania audiofilskicj napedow HDD :D :D :D

[PPM]

Wyświetl postUżytkownik PPM dnia 13.09.2012 - 11:30 napisał

Ja jakoś nie zauważyłem błędów w plikach tekstowych czy graficznych, czy jakichkolwiek innych, a niektóre posiadam od ok. 20 lat

 

Ale co Ty tym zdaniem chcesz zaprzeczyc ze jitter nie wplywa na przetwarzanie C/A?

 

Proszę nie mieszajmy domen cyfrowej z analogową, choć zaraz usłyszę, że cyfrowa to też analogowa. Napisałem, że w przypadku plików w formie cyfrowej zawierających dane tekstowe czy graficzne problem przekłamań nie istnieje, ale wg Ciebie w muzycznych istnieje. Kopiowanie w domenie cyfrowej odbywa się z korekcją błędów, więc jeżeli przegrany plik nie zgadza się ze źródłowym to system "wywala" błąd. Nie ma takiej możliwości, żeby przegrany plik był inny od źródłowego - stąd moje twierdzenie, że 20-letnie teksty są takie same jak... 20 lat temu, mimo wielokrotnego kopiowania. Nic się nie zmieniło.

 

Mam takie proste zadanie/pytanie i odpowiedź na nie może wg mnie zamknąć dyskusję z powodu niemożności przebicia "betonu":

Wyobraźmy sobie, że mamy plik z muzyką, np. 10 sekundowy WAVE 16/44 - co oczywiste w formie cyfrowej. Teraz dokonujemy jego czysto ANALOGOWEGO skopiowania poprzez... kartkę i długopis, albo dla ułatwienia, drukujemy po "hexach" przez drukarkę :) Teraz, albo dłużej, tworzymy nowy plik i wklepujemy bit po bicie, albo wrzucamy wydruk na program do rozpoznawania tekstu. Przeszliśmy znowu do CYFROWEGO zapisu. Dla pewności sprawdzamy sumy kontrolne pliku przed i po operacji "kopiowania". Czy po tej operacji dźwięk zmieni swoją sygnaturę? A może użycie karki i długopisu zabrzmi inaczej jak z drukarki? A może kolor długopisu będzie miał wpływ?

 

Powyższe można przenieść na ripowanie płyt z różnymi prędkościami i programami. Jeżeli skopiujemy utwór z płyty - programem A z prędkością X - i porównamy z tym samym utworem skopiowanym programem B z prędkością Y i porównamy je bit po bicie i okaże się że bitowo są identycznie to nie ma opcji żeby zagrały INACZEJ. Chyba, że ktoś ma skopany system odtwarzania.

[Stasiop]

Rozumie Cie co chcesz przekazac ale Twoj problem lezy w tym ze nie rozumiesz w jaki sposob drgania zegara .wplywaja na sygnal przetwarzany w przetworniku. Poczytaj wczesniejsze moje wpisy walkowalem to kilka razy. A problem jitteru wystepuje tylko w przypadku przetwarzania na postac analogowa.

Na tej kartce co bedziesz pisal te kolejne bity zawsze bedzie to samo nawet jak bedziesz przepisywal to milion razy.Ale problem nie lezy tutaj w tym ze wartosci danych sie zmienia ABSOLUTNIE problem lezy ze docierac one beda w nierownych porcjach czasowych tu jest problem! tylko TU!

 

 

A rippowanie plyt i wplyw tego na dzwiek to juz duzo duzo bardziej skomplikowana historia ;)

 

Pozdrawiam Stasiop

[PPM]

StasioP,

 

Trochę rozumiem dlaczego inni sceptyczni koledzy nie wchodzą dalej z Tobą w polemikę - nie odnosisz się bezpośrednio do tego co ktoś pisze tylko przechodzisz do innego tematu. Nie odpowiedziałeś, czy specyficznie przepisany wg mnie plik zagra inaczej.

 

Nie neguję, że masz sporą wiedzę, dlatego nie wchodzę w polemikę na temat C/A.

 

Ja ciągle piszę o domenie cyfrowej i odnoszę się do tych Twoich zdań:

"A wiecie ze slychac nawet rodzaje ripperow malo tego wplyw ma nawet predkosc zgrywania!!!"

"A jesli chodzi o roznice w brzmieniu 100 kopii to istnieje taka mozliwosci oczywiscie plik bitowo bedzie nawet na milionowej kopii logicznie spojny ale czasowo juz nie bo tak naprawde nagrywany bedzie na analogowym nosniku.

Ale w skrocie moge tylko powiedziec ze najprowdopodnie chodzi tu o kumulacje bledow czasowych na dysku twardym."

 

Pytanie brzmi czy "czasowa niespójność" analogowego zapisu spowoduje błąd przy odczycie. Bo jeżeli twierdzisz, że tak, to komputery można wyrzucić do kosza. Jeżeli jednak da się przy odczycie odtworzyć idealnie zapisany plik to nawet gdy nie odbywa się to za każdym razem w idealnie tym samym czasie - bo przecież system Windows nie jest systemem czasu rzeczywistego i wszystko opiera się na kolejkach i żądaniach dostępu - to odpowiedni bufor który znajduje się zarówno w programie do odtwarzania jak i w samym przetworniku C/A skutecznie odseparowuje od tych ewentualnych problemów odczytu. Jak nie odseparuje to... "pojawi się" cisza na wyjściu bo opróżni się bufor.

 

Jeżeli jednak to co piszesz jest prawdą to nie pozostaje nic innego, jak założyć firmę która zajmie się tworzeniem audiofilskich sterowników do dysków twardych, albo najlepiej SSD, gdzie specjalny, koniecznie DEDYKOWANY program do kopiowania w tandemie z tym sterownikiem, będzie w stanie tak umieszczać plik w komórkach pamięci, że będą idealnie ciągle poukładane. Przy odczycie, zsynchronizowanym atomowym zegarem, dane mogą być podawane bezpośrednio do DAC bez pośrednictwa całego syfu systemu. Myślę, że taki twór znalazłby całą rzeszę nabywców w cenie o jakiej nam się nie śni, bo przecież zapewniałoby idealne źródło danych.

[Stasiop]

Nie odpowiedziałeś, czy specyficznie przepisany wg mnie plik zagra inaczej.

A jak mam dyskutowac jak tu niektorzy ludzie nie maja pojecia jak wplywa jitter na przetwarzanie analogowe wiec co mam ciagle to samo walkowac?! Odpowiadam Ci problem nie lezy w danych tylko mozna powiedziec ze jesli bedziesz to przepisywal na kartke np co 1 sekunde regularnie jeden bit to przetwarzanie bedzie mialo mniej znieksztalcen jesli zaczniesz to przepisywac jeden bit za 2 sekund 3 bit co 5 sekund 4 bit co godzine piaty co 10 min wtedy znieksztalcenia sie pojawia. Bo przetwarzanie C/A czy A/C musi miec bardzo stabilny zegar ktory to przepisywanie bedzie nadzorowal a jesli to przepisywanie bedzie nieregularne to powstana znieksztalcenia i ta nieregularnosc nazywana jest jitterem

Tu lezy problem rozumiesz?

 

Pytanie brzmi czy "czasowa niespójność" analogowego zapisu spowoduje błąd przy odczycie.

O jaka niespojnosc Ci chodzi nie rozumiem pytania?

Ale powiem Ci jedno zeby gadac o znieksztalceniach ripperow to musisz najpierw zrozumiec jaki mechanizm jest powstawania znieksztalcen przez nieregularnosc zegarow. Jitter to nie jest prosty temat! tego nie da sie tak wytlumaczyc na kolanie!

 

Jeżeli jednak to co piszesz jest prawdą to nie pozostaje nic innego, jak założyć firmę która zajmie się tworzeniem audiofilskich sterowników do dysków twardych, albo najlepiej SSD, gdzie specjalny, koniecznie DEDYKOWANY program do kopiowania w tandemie z tym sterownikiem, będzie w stanie tak umieszczać plik w komórkach pamięci, że będą idealnie ciągle poukładane. Przy odczycie, zsynchronizowanym atomowym zegarem, dane mogą być podawane bezpośrednio do DAC bez pośrednictwa całego syfu systemu. Myślę, że taki twór znalazłby całą rzeszę nabywców w cenie o jakiej nam się nie śni, bo przecież zapewniałoby idealne źródło danych.

Podobne rzeczy juz robia np robia dlugie FIFO ktore pozwala sie odciac od tych zaklocen i synchronizuja atomowym wzorcem czasu polaczonym z ovenowanymi generatorami z super niskim jitterem i biora za to kosmiczna kase. Ja uwazam ze dlugie FIFO powinno te problemy wszystkie z komputerem wyciac w 99%

 

Mnie np do tego ze minimalizacja jitteru jest kluczowa na jakosc przetwarzania dzwieku przekonaly plyty XRCD-one graja lepiej niz te SACD czy DVD-audio w 90% a to tylko 44.1kHz i probkowanie 16 bitow

 

nie wchodzę w polemikę na temat C/A.

Jak nie wchodzisz w polemika na temat C/A to nie mamy wogole po co dyskutowac bo tam wlasnie to cale rozedrganie powoduje znieksztalcenia i tam jest caly problem!!!

 

Bo tu chodzi o to ze te dane chodza na ogromnych predkosciach i z duza stromoscia narastajacego sygnalu takie gwaltowne przelaczania z ogromnymi predkosciami V/t powoduja ostre zaklocenia ktore powoduja przesuwanie sie czasowe zboczy i to jest wlasnie jitter!

[Gość SlawekR]

.....

Problem ujawnia sie dopiero przy przejsciu na swiat analogowy. problemem jest przetwarzanie C/A bo ono musi miec super dokladne przedzialy czasowe aby sygnal byl przetworzony wiernie......

.....

One dotycza wszystkich problemow gdzie nastepuje przejscie z cyfry na analog tylko technika to w zaleznosci jak to jest skonstruowane zwielokratnia.

 

Ostatnie Twoje zdanie jest wielce znaczące. Oznacza, że od tego jak zdjęcia będą zapisywane na dysku i która to już będzie kopia zdjęć, będzie zależeć jakość ich wyświetlania na ekranie monitora, podłączonego do karty graficznej za pomocą analogowego złącza D-sub? No bo inaczej być nie może, skoro w karcie graficznej mamy konwersję z cyfry do analoga, za pomocą przetworników wbudowanych w grafikę. To i ten proces musi podlegać tym samym regułom.

 

To baaaaaardzo ciekawa teoria, na szczęście wyjątkowo łatwa do zweryfikowania. Powszechność raportowania pogorszenia jakości zdjęć wyświetlanych na monitorach, po procesie kopiowania, jest tak duża, że łeb odpada LOL.

 

 

A ucho jest chyba dziwnym organem ze slyszy takie niuanse sam sie nad tym czesto zastanawiam...Mysle ze jest to kwestia ewolucji ze w przyrodzie nigdy nie bylo takich efektow jak jitter wiec mozg to interpretuje jako cos bardzo innego od tego co nauczyla mozg ewolucja

 

Dobrze że się nad tym zastanawiasz, szkoda tylko że tak jednostronnie. A może warto wziąć pod uwagę, że ucho nie jest samodzielnym organem, a jego działanie jest absolutnie ściśle i nierozerwalnie połączone z działaniem mózgu i to on gra w tym wszystkim pierwsze skrzypce i potrafi płatać paskudne figle interpretacją działania zmysłów.

 

EDIT

Mam szczerą nadzieję, że odniesiesz się do tego co napisałem o wyświetlaniu zdjęć na ekranie monitora, do którego dostarczono analogowy sygnał po konwersji C/A, a nie uciekniesz standardowo w bok z dyskusją. Bo to przecież klasyczny przykład na odzwierciedlenie warunków, które są podstawą Twojej teorii.Różnica jest tylko taka, że w tym przypadku oko, a dokładniej mózg, trudniej oszukać, niż ma to miejsce w przypadku dźwięku. Więc jak, będzie różnica w wyświetlaniu zdjęć?

[PPM]

StasioP,

 

Czy ja kolejny raz mam powtórzyć, że nie neguję, że przy samym ODTWARZANIU plików muzycznych mogą następować pewne procesy na temat których ja się nie wypowiadam, bo nie mam takiej wiedzy, ale proszę Cię, nie szerz takich informacji jak grające rippery z różnymi prędkościami, albo cytując: "kumulacje bledow czasowych na dysku twardym".

 

Tak dla rozluźnienia już słyszę potencjalną rozmowę "audiofilów":

- Zdzichu, zgrałem nową płytę kapeli X przy pomocy EAC, z prędkością 1x z AccurateRip

- No co ty, ja nie mogę. Nie mam 10-letniego audiofilskiego Plextora i nie mogę zgrywać 1x, przegrasz mi?

- Mogę Ci przegrać, ale wtedy to już nie będzie to samo, sam wiesz...

- No wiem, trochę się zmieni przy kopiowaniu. Muszę z tym żyć.

 

Tylko, żeby jakiś Zdzisław się nie obraził :)

[Stasiop]

Mam szczerą nadzieję, że odniesiesz się do tego co napisałem o wyświetlaniu zdjęć na ekranie monitora, do którego dostarczono analogowy sygnał po konwersji C/A, a nie uciekniesz standardowo w bok z dyskusją.

Jesli chodzi o zdjecia to nie wiem jak bedzie bo prawdopodobnie temat jest podobnie tak samo mocno skomplikowany jak przy audio. Ale gdzies mi sie obilo o uszy ze w aparatach fotograficznych tym sie zajmuja tzn jitterem. Ale jitter rowniez i w tych przetwornikach z pewnoscia teoretyczny bedzie ale czy to widac to nie mnie oceniac ;) nie wiem!

 

Ale co Ty w tej chwili Slawek chcesz udowodnic ze co jitteru wogole nie slychac? Bo wszystko na to wskazuje ze dyskusja zmierza w ta strone.

 

Różnica jest tylko taka, że w tym przypadku oko, a dokładniej mózg, trudniej oszukać, niż ma to miejsce w przypadku dźwięku.

Te badania jesli chodzi o psychoakustyke oka czy ucha mozna sobie miedzy bajki wlozyc ciagle cos nowego odkrywaja np ostatnio slyszalem ze ucho wewn slyszy podprogowo do 200kHz a kiedys mowili 22khz to jest maks co czlowiek moze slyszec

[grzeseik]

tak sobie czytam ten wątek i przyszła mi taka myśl do głowy:

nieraz sie w różnych wątkach powtarza takie stwierdzenie, powtarzane przez kolegów o różnych ogolnie poglądach że jednego dnia im sie lepiej słucha, innego dnia jakby gorzej. dociakają ze moze zmęczenie, samopoczucie, ze prąd inny, szukają powodów...

a to im sie nocą defragmentacja dysków z kolekcją porobiła!

[Stasiop]

ale proszę Cię, nie szerz takich informacji jak grające rippery z różnymi prędkościami, albo cytując:

Tematem sie zajmiemy kiedy bedzie na to czas temat jest bardzo skomplikowany i trzeba miec duza wiedze jesli chodzi o zaklocenia sposoby zapisu na dysku (na ktorego temat za duzo nie wiem obecnie, ale czytam tzn chodzi mi o HDD) To zjawisko niestety slychac sam slysze i powoli biore sie za jego wyjasnianie ( bo wszystko mozna wyjasnic logicznie jesli chodzi o technike) a jesli chodzi o grajace rippery to nie jestem pierwszy ktory tak twierdzi kolesie z The Absolute Sound to szybciej stwierdzili a ja potwierdzam w niezaleznych odsluchach, zreszta kilka osob ze swiatka high-endu o tym mowilo juz kiedys - wtedy ich wysmialem a teraz szukam wyjasnienia sprawy i jestem juz bliski ;)