Bit Perfect - Zakazane Słowo

[Bahzell]

5 minut temu, yacool napisał:

No ale piszesz oczywistości które już przetrawiliśmy w tym wątku, przeczytaj

Przeczytałem. 

1. Piszesz o kablach zasilających

2. Piszesz o algorytmach, które potrafią odzyskać informację na podstawie nie pewnych danych. Swoją drogą tu bym tak odważnie nie twierdził. Powiedział bym, że algorytmy potrafią spróbować odzyskać informację i zgadnąć na podstawie tego co dookoła jak powinno być faktycznie. 

3. Piszesz o tym że kable nie mają żadnego znaczenia, co najwyżej złote styki. 

A ja piszę o tym, że kable przy tak dokładnym pomiarze mogą mieć znaczenie. Tylko czy to ma znaczenie wobec subiektywnego absolutu?

[Chyba Miro 84]

14 minut temu, Bahzell napisał:

@up

Tak samo jak nie ma przechowywania danych w pamięci RAM. 

A czy ram to tylko przewody??? Tak powstaje voodoo

20 minut temu, yacool napisał:

Porządkuje: nie ma przechowywania danych "w kablach"

 

Tez probuje to oznajmić

[Gość]

6 minut temu, Kraft napisał:

Myślę jednak, że nieprzekonanych i tak nie przekonasz. 0,0001 dB głośności? Ok - powiedzą - może i tak. Ale co z separacją instrumentów, głębią stereofonii i namacalnością? Ich nie da się określić w dB. Ten test niczego więc nie dowodzi - zakończą.

Jak już pisałem na początku, nie będę nikogo na siłę przekonywać. To temat dla ciekawych i chcących poznać/ustalić prawdę. 

Separacja instrumentów, głębia stereofonii itp - to wszystko jest już zawarte w zapisanym pliku muzycznym. 

Ale weź tu kurna wyjaśnij tym co nie chcą 

[Bahzell]

Zawsze mi się wydawało że Delay line memory to przechowywanie danych w kablach. Ale w sumie mogłem się mylić. 

[yacool]

22 minuty temu, JohnDoe napisał:

Ja też jestem ciekawy. Mam jednak mały problem. Nie wiem jak wypalić na płycie CD-R nienaruszone pliki testowe wav. Za każdym razem te pliki po wypaleniu zmieniają nazwę na cda i to już nie jest bit-perfect. Na tak wypalonej płycie próbowałem wczoraj i test nie przechodzi. Może ktoś z Was szanowni wie jak wypalić takie pliki wav aby były ciągle takie same? 

Płyta audio ma inną strukturę niż płyta z danymi. Nie ma tam plików tylko ścieżki - tego akurat nie zmienisz. 

Po drugie - nie widzę powodu, żeby nazwa miała być znacząca przy sprawdzeniu - jeśli tak jest, to czegoś nie rozumiem

Zakładam, że po stronie samych danych to co nagrasz powinno być (zerojedynkowo zapisana) ta sama informacja - ale nie wiem, czy tu program nagrywający, albo nagrywarka czegoś nie modyfikuje - np. w nagłówku....

Jednak praca dyplomowa ...

[Gość]

Podczas testu z tak wypalonej płyty słychać takie samo "pykanie" z głośników jak z oryginalnego pliku testowego,  ale bit-test nie jest zaliczony. Dla ludzkiego ucha to jest to samo, jednak dla bit-testu już nie. Nie wiem jak to ogarnąć. Zapytałem na forum RME czy w ogóle da się wypalić pliki testowe na CD-R i tak przeprowadzić test transportów CD. 

[yacool]

26 minut temu, Bahzell napisał:

Przeczytałem. 

1. Piszesz o kablach zasilających

2. Piszesz o algorytmach, które potrafią odzyskać informację na podstawie nie pewnych danych. Swoją drogą tu bym tak odważnie nie twierdził. Powiedział bym, że algorytmy potrafią spróbować odzyskać informację i zgadnąć na podstawie tego co dookoła jak powinno być faktycznie. 

3. Piszesz o tym że kable nie mają żadnego znaczenia, co najwyżej złote styki. 

A ja piszę o tym, że kable przy tak dokładnym pomiarze mogą mieć znaczenie. Tylko czy to ma znaczenie wobec subiektywnego absolutu?

Tak - żaden algorytm nie odzyska danych, które zostały zdegradowane w zbyt dużym stopniu. 

Nie napisałem że kable nie mają znaczenia (kropka) - uważam że kabel nie może wpływać na brzmienie WTEDY kiedy  po drugiej stronie mamy stwierdzone, że po przesyle są to dokładnie te same dane które zostały nadane (czyli mamy bit perfect) - wtedy - niezależnie od medium po drodze - po stronie odbierającej mamy DOKŁADNIE ten sam zestaw zer i jedynek. 

Możesz te zera i jedynki dowozić kablem optycznym, miedzianym, albo donosić wiadrami - nie ma to znaczenia. 

Na marginesie - zaznaczam, że nie jestem żadnym specjalistą od Bit Pefrect, ani algorytmu odczytu danych z płyt, ani algorytmu przesyłu i korekcji danych audio. 

Przykładam swoją wiedzę z innych dziedzin - jeżeli sie mylę w moim rozumowaniu - chętnie dowiem się gdzie. 

 

1 minutę temu, JohnDoe napisał:

Podczas testu z tak wypalonej płyty słychać takie samo "pykanie" z głośników jak z oryginalnego pliku testowego,  ale bit-test nie jest zaliczony. Dla ludzkiego ucha to jest to samo, jednak dla bit-testu już nie. Nie wiem jak to ogarnąć. Zapytałem na forum RME czy w ogóle da się wypalić pliki testowe na CD-R i tak przeprowadzić test transportów CD. 

A czy są transporty/odtwarzacze CD z opcją BIT PERFECT? Może to tylko technologia zastrzeżona dla DAC-ów? 

[Gość]

2 minuty temu, yacool napisał:

A czy są transporty/odtwarzacze CD z opcją BIT PERFECT? Może to tylko technologia zastrzeżona dla DAC-ów? 

Każdy transport CD który ma gniazdo USB memory - mogę przetestować bez problemu. Mnie jednak chodzi o test z płyty CD. To nie jest technologia zastrzeżona dla żadnego urządzenia. Badamy nie urządzenie ale cały tor cyfrowy audio z punktu A do punktu B i nie ważne co jest po drodze bo wszystko co jest zawarte w tym torze jest przedmiotem testu 🙂          Może być nawet wiadro

[Fafniak]

1 minutę temu, JohnDoe napisał:

Każdy transport CD który ma gniazdo USB memory - mogę przetestować bez problemu. Mnie jednak chodzi o test z płyty CD.

Ale prościej jest zgrać plik na CD

wgrać go do programu edytujacego

wgrać źródłowy plik i odwrócić w fazie jeden z nich

Jak nic nie zostanie to pliki są identyczne

wbij "null test"

 

26 minut temu, Bahzell napisał:

Zawsze mi się wydawało że Delay line memory to przechowywanie danych w kablach. Ale w sumie mogłem się mylić. 

Specjalnie mieszasz w wątku?

Jeżeli nie specjalnie to bardzo cię prosze przeczytaj jeszcze raz o jakim teście pisze @JohnDoe (dodam ze ten test dodatkowo eliminuje wpływ tego o czym ty piszesz) a dwa to wydaje mi się że linie opóźniajace chyba były specjalną konstrukcją i nis ekładały sie z kabelków 1m. Dotyczyły innych przedziałów czasowych... itd. Jeżeli masz jakieś opracowanie które świadczy o tym ze takie zjawisko moze występować w kabelku 0,3m-2m to prosze podaj

[Gość]

4 minuty temu, Fafniak napisał:

Jak nic nie zostanie to pliki są identyczne

Nawet jeśli pliki z wypalonej płyty będą identyczne (w null test) to wciąż nie pozwala mi to na bit testowanie lasera i poprawności odczytu całego mechanizmu optycznego w innym transporcie CD.     To o czym piszesz może (choć nie musi) potwierdzić poprawność działania CD rom w moim laptopie.     Tak to rozumiem, jeśli źle proszę popraw. 

[yacool]

1 minutę temu, JohnDoe napisał:

Nawet jeśli pliki z wypalonej płyty będą identyczne (w null test) to wciąż nie pozwala mi to na bit testowanie lasera i poprawności odczytu całego mechanizmu optycznego w innym transporcie CD.     To o czym piszesz może (choć nie musi) potwierdzić poprawność działania CD rom w moim laptopie.     Tak to rozumiem, jeśli źle proszę popraw. 

Weryfikacji i tak poddajesz cały łańcuszek: a więc mech. optyczny i przesył kablem na stronę odbierającą. 

[Fafniak]

fakt - zapętliłem się

musiałbyś mieć wejście cyfrowe

A ten twój RME chyba nie ma ?

[Gość]

Nie rozumiem o jakie wejścia pytasz  🤔        Jest input -  SPDIF Coax, Optyk i USB. 

[Fafniak]

ahh

ale czy ten RME potrafi robić za wejście cyfrowe dla komputera ?

chodzi o nagranie cyfrowego przekazu z płyty - jakiegoś utworu i zrobienei null testu

[MobyDick]

W przypadku odczytu płyty CD sądzę że przejście takiego testu nie będzie możliwe. Przesył danych przez złącze typu SPDIF nie należy do pakietowych i korekcja błędów danych nie będzie możliwa z powodu jednokierunkowych interfejsów. Błędy odczytu danych w takim procesie są nieuniknione. Ponad 100 takich błędów w ciągu sekundy jest tu normalne.  Korekcja błędów sprowadza się co najwyżej do analizy przebiegów sygnału analogowego.

[Gość]

No właśnie, laser może już nie będzie taki "stabilny" jak kabel. Nie wiem tego. Czekam na odpowiedź z RME czy można taki test w ogóle przeprowadzić. 

[Kraft]

Tu jest ładnie opisane, jak wygląda sprawa błędów w odczycie płyt CD.

https://komputery-pc.info/budowa-pc/napedy-optyczne/item/70-obsluga-bledow-odczytu

Transport CD chyba nie przejdzie testu.

[Bahzell]

19 minut temu, Fafniak napisał:

Specjalnie mieszasz w wątku?

Jeżeli nie specjalnie to bardzo cię prosze przeczytaj jeszcze raz o jakim teście pisze @JohnDoe (dodam ze ten test dodatkowo eliminuje wpływ tego o czym ty piszesz) a dwa to wydaje mi się że linie opóźniajace chyba były specjalną konstrukcją i nis ekładały sie z kabelków 1m. Dotyczyły innych przedziałów czasowych... itd. Jeżeli masz jakieś opracowanie które świadczy o tym ze takie zjawisko moze występować w kabelku 0,3m-2m to prosze podaj

Przecież w pierwszym swoim poście to napisałem. Żeby skrócić maksymalnie kabel i zminimalizować ten efekt. A ten test nie eliminuje tylko weryfikuje. Jeśli chodzi o to czy linia opóźniająca była specjalną konstrukcją, nie. Była to implementacja tego że informacja rozchodzi się w medium z konkretną prędkością. Jeśli chodzi o wielkość to np w pierwszych monitorach z lat 60tych używano tego rozwiązania. Czas dostępu do takiej pamięci był rzędu 500 mikrosekund, a wymiar to np. 30 na 30 cm. 

A zjawisko występuje chociażby w procesorach których używamy teraz. Jest to efekt minimalny, ale przy taktowaniu procesora kilku gigaherzów może już wpływać na spadek wydajności, utratę danych i tak dalej. 

[Fafniak]

Napisałem że test który przeprowadził @JohnDoe wyeliminował wpływ. Ok. nieprawidłowo napisałem. Faktycznie powinienem napisać zweryfikował (negatywnie) wpływ tego zjawiska.

Ja rozumiem że to zjawisko występuje ale chciałbym abyśmy rozmawiali o sprawach które znajdują się w rzeczywistym systemie i zakresie "mierzalnym"

Czy przy częstotliwościach przesyłu danych i długościach przewodów  jaki wartościach napięć reprezentujących 0 i 1, czy  to zjawisko jest mierzalne w zakresie wartości które mogą wpływać na odbiór danych?

Ten podany na końcu wymiar dotyczy obudowy?  A nie długości kabla ? (jak mi sie wydaje)

[Gość]

1 godzinę temu, JohnDoe napisał:

Czekam na odpowiedź z RME czy można taki test w ogóle przeprowadzić. 

Oto jedna z odpowiedzi użytkownika tamtego forum. Wciąż czekam, może inżynier RME coś napisze. 

https://forum.rme-audio.de/viewtopic.php?pid=152377#p152377

 

 

Przepraszam za "googlowe" tłumaczenie z angielskiego (co mogłem to edytowałem na szybko). Mimo to, dość czytelne i zrozumiałe:

 

Cytat:

"Potrzebujesz oprogramowania, które można ustawić do nagrywania „CD Audio” (Audio CD), a nie „CD ROM” (dysk z danymi).

To jest zupełnie inny format.

„CD Audio” musi zostać „sfinalizowane”, co oznacza, że końcowy „Table Of Contend” jest nagrywany na płycie i nie można go już zmienić.

Następnie można go odtwarzać na każdym odtwarzaczu CD.

Nie jestem pewien, czy jest to już część systemu Windows 10, ponieważ używam do tego mojego DAW, ale istnieje wiele programów, które to robią.

Audio CD obsługuje tylko 16-bitowy format 44,1 kHz.

 

Rzeczy, których nigdy nie chciałeś wiedzieć o płytach CD:

 

„CD Audio” różni się od „CD ROM”, ponieważ nie zawiera „plików”, ale „ścieżki”.

„CD Audio” ma strukturalnie więcej wspólnego z płytą winylową niż objętością danych: (cyfrowy) dźwięk umieszczony sekwencyjnie na spiralnej ścieżce na płycie, bez dokładnych adresów lokalizacji podłączonych do strumienia, z wyjątkiem „Ścieżki nr”, ograniczony do 99.

W przeciwieństwie do CD ROM, ułożonego w sektory, każdy blok danych ma swój własny numeryczny adres.

 

Dlaczego to wyjaśnienie:

Z powodu braku adresów płytę Audio CD można odczytywać nieprzerwanie, sekwencyjnie.

Komputery często mają problemy odczytać bit-perfect z płyty Audio CD, ponieważ mają tendencję do szybszego czytania w blokach i buforowania / buforowania danych, a następnie próbują wrócić i odczytać następny blok danych.

Ale nie ma dokładnego adresu, do którego mogłyby się udać, więc muszą czytać w nakładających się blokach i patrzeć na treść, aby znaleźć właściwą pozycję do „ponownego montażu” fragmentów, co często się nie udaje.

 

Dlatego zdany test bitowy RME na komputerowym transporcie CD niekoniecznie oznacza, że będzie on odtwarzał bit-perfect przez cały czas.
Test bitowy RME jest bardzo krótkim sygnałem, który znajduje się w jednym bloku odczytu.
Nie powoduje to wymienionych problemów.
W rzeczywistości jednak pokazuje, że ścieżka odtwarzania jest transparentna,  dokładna bitowo.

 

Archiwa strumieniowych usług audio, takich jak Spotify, Tidal, Deezer itp., Są pełne źle zgranych kopii płyt CD pełnych kliknięć, takich jak np. Album Joe Body „Body And Soul”.

Edytowano 30 marca 2020 przez Gość

[MariuszZ]

W tym wątku koledzy próbowali rozkminić jak sprawdzić transport CD pod kątem przesyłu "bit perfect". Wcześniej pisałem o tym. Potrzebna płyta CD pliki z wątku i dekoder amplitunera AC3. Czy to tak działa? Nie wiem ale można podyskutować  

[Gość]

Czytałem to. Nie do końca rozumiem co jest normą/wyznacznikiem w takim teście. Słuch? Bo gra muzyka? Dla mnie to podejrzane 🤔 Ale pewności nie mam, więc podyskutować oczywiście warto 

[yacool]

No dobrze, trochę bliżej sedna - pisałem że szczegółów nie znam, więc trochę podrążyłem i kilka tropów. 

Za przesył danych audio cyfrowych odpowiada protokół AES3 (https://en.wikipedia.org/wiki/AES3#Protocol). 

Protokół - zgodnie z moją wcześńiejszą intuicją - obsługuje mechanizmy wykrywania błędów - poniżej fragment z jakiegoś forum:

So reading through https://en.wikipedia.org/wiki/AES3

-------------------------------

it seems that it uses a simple parity-bit mechanism to detect errors, but there is no re-transmission or redundancy built in to the data-stream. Meaning:

If a frame gets corrupted:the receiver may detect it as corrupt via the parity bit:

in which case it can either ignore the frame (silence gap) or try to play it anyway (some audio degradation)

if the parity bit check fails to identify the error, the receiver will just play it, which will lead to some level of degradation

This means to me that a crappy long toslink cable could potentially lead to poorer sound quality, though I'm not sure these days how common that is...

------------------

Czyli w skrócie są sprawdzane sumy kontrolne i jeśli wykryto błąd zastępowany jest "brakiem sygnału" (silence gap).

W specyfikacji protokołu (ramka nr 27) jest też sekcja Validy z ciekawym opisem:

Unset if the audio data are correct and suitable for D/A conversion. During the presence of defective samples, the receiving equipment may be instructed to mute its output. It is used by most CD players to indicate that concealment rather than error correction is taking place.

 

Jeszcze coś: zliczanie takich parity bits (czyli licznik błędów) mógłby być sensownym sposobem sprawdzenia poporawności transmisji. 

BIt Perfect - jeśli dobrze zaczynam rozumieć - to tylko jakieś wzorce wrzucone w cały stream które są wykrywane po stronie odbioru. Jeśli następuje degradacja, to nie jest badany cały "stream" tylko te fragmenty z wzorcem. Czyli jeśli degradacja nastąpiłaby w innym miejscu - pozostałaby niezauważona. ALe to moja intuicja, bo nadal nie wiem, jak ten bit perfect działa

I jeszcze detaliczne opracowanie protokołu: jest tam wszystko o czym mówiłem: synchronizacja zegara, korekcja błędów, jittery

https://tech.ebu.ch/docs/other/aes-ebu-eg.pdf

[yacool]

I bardzo ciekawy fragment:

Wydaje się więc że protokół daje pewną dowolność w jaki sposób reagować na błędy i poszczególne aplikacje mogą to obsługiwać w różny sposób. Tym trudniej będzie ustalić jeden wiarygodny test na zgodność

O, właśnie:

"Error concealment can be carried out very simply by interpolation between neighbouring samples. This method generally gives good audible results at the output of D-A converters."

Czyli jeśli próbka X jest błędna, bierzemy próbki X-1 orax X+1, uśredniamy i mamy "odgadniętą" próbkę X

To jest to wypychanie "sianem" o którym pisałem "intuicyjnie"

Cały rozdział 6 pokazuje możliwości testowania jakości przesyłu danych. 

Jeszcze raz: to temat na pracę dyplomową. A kto wie - może nawet więcej

[Gość]

Sporo informacji ale przeczytałem. Czytałem też inne i chwilami już mam mętlik w głowie.    

 

 

Wcześniej nie zwróciłem na to uwagi ale teraz wydaje mi się, że bit test jest czymś innym i odbywa się w procesie D-D  a więc nie obejmuje punktu gdzie mogą się pojawić ewentualne błędy spowodowane przez jitter czy inne związane z D-A. Bit test nie ma za zadanie określić jakości konwersji D-A ale tylko poprawność przesyłu oryginalnych danych. Poplątało mi się trochę wszystko 

 

To z instrukcji obsługi DAC: 

  "A bit test is used to check the playback path for unwanted changes in the playback data" - a więc sprawdza tylko czy zapis pliku nie został zmieniony na wejściu DAC. Zanim jeszcze dojdzie do przetworzenia D-A.

"The short, but efficient test sequence allows to check for the following changes and errors: Level changes, equalization, dynamic processing, polarity, channel swapping, sample offset, hanging or twisted bits, dither, bit reduction".

 

 

 

 

 

Edytowano 30 marca 2020 przez Gość