Foobar już nie jest odtwarzaczem typu bitperfect.

[Klimkr]

W końcu pokazała się finalna wersja Foobar2000 v2.0.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[negatyw]

Ja dopiero dziś zauważyłem, że jest wersja 2.0. I to w wersji klasycznej i 64bit.
Wersja klasyczna, pozwala się instalować jako upgrade. Coś mnie jednak przed tym wstrzymało...

Teraz czytam pobieżnie wątek i piszecie o uwaleniu natywnego przesyłu plików.

Posiadam cały czas wersję 1.6.16. Zatem pliki DSD są natywnie przesyłane do DAC po PC-USB.
Reasumując - nie warto aktualizować do nowszych wersji?
Czy dobrze to rozumiem?

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[yayacek]

Muszę trochę wyprostować temat.
Wątek ten dotyczył foobara przed wersją 2.0 i funkcji FADING, która na słuch coś psuła choć pomiary tego nie potwierdzały.
Nie wiem co było przyczyną, że w foobarze 1.6.x dźwięk się nieznacznie zmieniał w zależności od tego czy opcja FADING była włączona bądź wyłączona.
Starałem się uzyskać informację na forum foobara jak działa opcja FADING i czym ona jest. Podano mi informację, że jest to dodatkowy bufor o bardzo niskim opóźnieniu (latencja) umieszczony między rdzeniem odtwarzacza a wtyczką wyjściową (ASIO/WASAPI). Bufor ten zasadniczo przepuszcza dane nie naruszając ciągu bitów. 
Naście dni temu zainstalowałem wersję najnowszą 2.0/32 bit i tutaj już nie słyszę żadnej różnicy przy włączonej jak i wyłączonej opcji FADING. Wszystko działa jak należy - bit perfect jest zapewniony.

Zasadniczo najbezpieczniej jest mieć opcję FADING wyłączoną - to najbardziej 'surowy' przekaz danych na wyjście. Jednak wiele osób będzie zmuszonych FADING włączyć gdyż to zapewnia najbardziej stabilną pracę foobara. Przy wyłączonym FADING może się zdarzać, że przewijanie wewnątrz utworu nie będzie płynne a niektóre sterowniki ASIO mogą wywoływać błąd przy przykładowo ręcznym przeskoczeniu do kolejnego utworu.

Reasumując - warto aktualizować. Warto wyłączyć FADING o ile nie psuje to stabilności działania foobara. Warto też wybrać odpowiednią wersję 32/64 bit w zależności od wtyczek jakich używamy.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Klimkr]

7 godzin temu, yayacek napisał:

Zasadniczo najbezpieczniej jest mieć opcję FADING wyłączoną - to najbardziej 'surowy' przekaz danych na wyjście. Jednak wiele osób będzie zmuszonych FADING włączyć gdyż to zapewnia najbardziej stabilną pracę foobara. Przy wyłączonym FADING może się zdarzać, że przewijanie wewnątrz utworu nie będzie płynne a niektóre sterowniki ASIO mogą wywoływać błąd przy przykładowo ręcznym przeskoczeniu do kolejnego utworu.

Reasumując - warto aktualizować. Warto wyłączyć FADING o ile nie psuje to stabilności działania foobara. Warto też wybrać odpowiednią wersję 32/64 bit w zależności od wtyczek jakich używamy.

Może to była kwestia sterownika, chociaż to mało prawdopodobne bo, jak rozumiem, dobrze działa z wersją 2.0.

Autor Foobara wręcz odradza używanie ASIO pisząc o foo_out_asio:

Please note that this component is meant for systems where ASIO is the only available output method. It is highly recommended to use the default output modes instead of ASIO. Contrary to popular "audiophile" claims, there are NO benefits from using ASIO as far as music playback quality is concerned, while bugs in ASIO drivers may severely degrade the performance.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[negatyw]

Ja nawet aktualnie korzystam z 1.6.11. Ale zrobię upgrade do 2-ki 32bit.

Poniżej moje ustawienia. Oceńcie proszę, czy wszystko jest pod bitperfect. Nie jestem mistrzem świata i jestem otwarty na podpowiedzi 🙂

 

 

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[marek.pap]

Proponuję w ASIO drivers zaznaczyć "Run with realtime process priority".
ReplayGain Scanner odznaczyć "Downsample high-definition content".
Zaznaczyć "True peak scan". Using ustawić [auto 4x oversample]

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Klimkr]

25 minut temu, marek.pap napisał:

Proponuję w ASIO drivers zaznaczyć "Run with realtime process priority".
ReplayGain Scanner odznaczyć "Downsample high-definition content".
Zaznaczyć "True peak scan". Using ustawić [auto 4x oversample]

Jeśli ma bć bitperfect to chyba trzeba Replay Gain wyłączyć?

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Można też sprawdzić jakie są ustawienia DSD Transcoder. U mnie jest inaczej, z AsioProxy:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[marek.pap]

18 minut temu, Klimkr napisał:

Jeśli ma bć bitperfect to chyba trzeba Replay Gain wyłączyć?

Ja mam wyłączony do odtwarzania, ale wykorzystuję do pomiaru True Peak i LUFS.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[yayacek]

5 godzin temu, Klimkr napisał:

Jeśli ma bć bitperfect to chyba trzeba Replay Gain wyłączyć?

19 godzin temu, negatyw napisał:

Oceńcie proszę, czy wszystko jest pod bitperfect

Oczywiście. Trzeba wyłączyć. Tak samo jak i każdy resampling czy każdą wtyczkę DSP i volume w foobarze na 0db. 

Ale to i tak nie gwarantuje przesyłu bit perfect. By się dowiedzieć czy przesył jest zgodny bitowo należy to zmierzyć/sprawdzić - np. za pomocą pliku testowego i zewnętrznego dekodera sprzętowego AC3/DTS czy dekodera sprzętowego HDCD.
Można też przechwycić sygnał na wyjściu cyfrowym i nagrać go cyfrowo a następnie dokonać sumowania w przeciwfazie sygnału przechwyconego z odtwarzanym plikiem, ale to jest trudniejsze do wykonania dla przeciętnego użytkownika, bo trzeba posiadać kartę dźwiękową z wejściem cyfrowym i podstawowe umiejętności z pracą na sygnałach cyfrowych i na edytorach dźwięku.

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 11 Maja 2023 przez yayacek

[negatyw]

Czym de facto jest "ReplayGain" ?

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[danadam]

56 minutes ago, negatyw said:

Czym de facto jest "ReplayGain" ?

Normalizacja głośności. Najpierw plik jest analizowany i w jego tagach jest zapisywana informacja o tym o ile powinien grać ciszej czy głośniej. Później, jak plik jest odtwarzany, to player może odczytać tę informację i automatycznie zmienić głośność.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Funnykris]

3 godziny temu, danadam napisał:

Normalizacja głośności. Najpierw plik jest analizowany i w jego tagach jest zapisywana informacja o tym o ile powinien grać ciszej czy głośniej. Później, jak plik jest odtwarzany, to player może odczytać tę informację i automatycznie zmienić głośność.

Warto dodać że jeżeli na wyjściu jest ustawione 24 lub 32 bit nie traci się kompletnie nic z jakości dźwięku. Muzyka będzie cichsza lub głośniejsza i to wszystko. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[fozzie]

9 godzin temu, Funnykris napisał:

Warto dodać że jeżeli na wyjściu jest ustawione 24 lub 32 bit nie traci się kompletnie nic z jakości dźwięku. Muzyka będzie cichsza lub głośniejsza i to wszystko. 

Nieprawda. Zawsze się traci. Ingerencja w zwartość bitową strumienia jest zawsze i zmienia całkowicie tę zawartość.

Już to było w tym temacie.

W dniu 12.03.2023 o 18:05, Funnykris napisał:

Replay Gain to informacja o tym ile db trzeba odjąć czy dodać żeby osiągnąć założony cel średniej głośności utworu. Odtwarzacz to czyta i to stosuje. Przy wyjściu do DAC w 24 bitach obcinane są dodane zera no chyba że utwór jest w 24 bitach. Wtedy najlepiej by było mieć DAC 32 bit. Niemniej jednak dla 99% plików 16 bit RG nie ma wpływu na dane jakie trafiają do DAC. 

Ciągle powtarzasz to samo a to nieprawda.

 

W dniu 12.03.2023 o 19:34, fozzie napisał:

Tylko, że jak zamienisz 16 na 24 bity to też automatycznie tracisz bitperfect, nawet bez TeplayGain, a o bitperfect jest tu mowa.

Dla plików 16 bitowych też ma to ogromne znaczenie i wpływ na to, co dociera do DACa.

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 12 Maja 2023 przez fozzie

[negatyw]

To może wrzuć swoje IDEALNE screeny ustawień i będzie konkretnie i rzeczowo?

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[yayacek]

6 godzin temu, fozzie napisał:

Nieprawda. Zawsze się traci. Ingerencja w zwartość bitową strumienia jest zawsze i zmienia całkowicie tę zawartość.

Oczywiście. Mam jednak wrażenie, że spora ilość osób zupełnie nie rozumie co to jest przekaz zgodny bitowo (bitperfect).
Zmiana głośności choćby o 0,1dB powoduje całkowitą utratę transmisji bit perfect - ciąg bitów po takiej operacji będzie całkowicie odmienny. 

16 godzin temu, Funnykris napisał:

Warto dodać że jeżeli na wyjściu jest ustawione 24 lub 32 bit nie traci się kompletnie nic z jakości dźwięku. Muzyka będzie cichsza lub głośniejsza i to wszystko. 

Owszem, będzie cichsza lub głośniejsza co znaczy, że sygnał nie jest bit perfect
Litwo, ojczyzno moja - plik oryginalny
Litwo, ojczyzno moja = przesył bit perfect
Litwo, ojczyzno moja = przesył niezgodny bitowo
$%&)#; GHuro^)! st5a = przesył niezgodny bitowo

O bitperfect mówimy tylko wówczas, kiedy ciąg danych na fizycznym wyjściu cyfrowym jest co do bita identyczny z materiałem odtwarzanym. W każdym innym przypadku mamy do czynienia z ingerencją w strumień danych.

Godzinę temu, negatyw napisał:

To może wrzuć swoje IDEALNE screeny ustawień i będzie konkretnie i rzeczowo?

Czysty foobar, bez resamplingu, bez replain gain, bez DSP, z protokołem ASIO/Wasapi exclusive z volume na 0dB - potem i tak trzeba sprawdzić ciąg bitów na zewnętrznym dekoderze sprzętowym AC3/DTS/HDCD czy wszystko jest OK i czy przypadkowo karta dźwiękowa (czy jakiś diwajs USB->SPDiF) na wyjściu cyfrowym nie robi jakiś chochlików.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[przemak]

6 godzin temu, fozzie napisał:

Tylko, że jak zamienisz 16 na 24 bity to też automatycznie tracisz bitperfect

Czyli co, biorąc pod uwagę specyfikację spdif:

"S/PDIF is meant to be used for transmitting 20-bit audio data streams plus other related information. To transmit sources with less than 20 bits of sample accuracy, the superfluous bits will be set to zero."

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

nie ma szans na bitperfect w ogóle? 😉

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Klimkr]

44 minuty temu, yayacek napisał:

Oczywiście. Mam jednak wrażenie, że spora ilość osób zupełnie nie rozumie co to jest przekaz zgodny bitowo (bitperfect).
Zmiana głośności choćby o 0,1dB powoduje całkowitą utratę transmisji bit perfect - ciąg bitów po takiej operacji będzie całkowicie odmienny. 

Owszem, będzie cichsza lub głośniejsza co znaczy, że sygnał nie jest bit perfect
Litwo, ojczyzno moja - plik oryginalny
Litwo, ojczyzno moja = przesył bit perfect
Litwo, ojczyzno moja = przesył niezgodny bitowo
$%&)#; GHuro^)! st5a = przesył niezgodny bitowo

 

A w MQA Studio byłoby: Litwo, Ojczyzno moja 🙂

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Funnykris]

8 godzin temu, fozzie napisał:

Nieprawda. Zawsze się traci. Ingerencja w zwartość bitową strumienia jest zawsze i zmienia całkowicie tę zawartość.

No nie jest bit Perfect. Ale nic się nie traci. W 32 bit można cyfrowo ściszać pliki 24 bit BEZ UTRATY DANYCH. Nie ma bit Perfect ale jakość dźwięku pozostaje bez zmian. Całość jest cichsza o jakąś wartość niemniej nic nie zostało nieprzekazane do DAC. Nigdzie nie ma straty na wysokości dźwięku danej próbki a dynamika pozostaje bez zmian. Całość można porównać do obrazka wydrukowanego 1 cm niżej niż oryginał. Dopóki nie dojdziemy do krawędzi kartki obraz pozostaje nienaruszony. 

2 godziny temu, yayacek napisał:

Owszem, będzie cichsza lub głośniejsza co znaczy, że sygnał nie jest bit perfect

tak! Ale jak wyżej - to nie ma znaczenia dla DAC w 32 bitach. A w przypadku plików 16 bit już w 24. 

Tak w ogóle to często w DAC i tak następuje resampling więc... To całe bit Perfect to czysta teoria. Jeżeli przetwornik i tak to zresampluje to ja wolę podać mu już zresamplowane dane. Przynajmniej wiem jaka jest jakość tego resamplingu.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[negatyw]

Dużo słów, a screenów nikomu się nie chce zapodać...

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[yayacek]

Nie istnieje pojęcie regulacji głośności w domenie bitperfect. To jest zaprzeczenie samo w sobie tak jak młody starzec.
Ściszając plik o choćby 0,1dB masz na wyjściu cyfrowym zupełnie inne dane niż w pliku źródłowym. Sumowanie w przeciwfazie pliku źródłowego i przechwyconego ciągu bitów na wyjsciu cyfrowym wyraźnie pokaże różnicę - zamiast cyfrowej ciszy dostaniesz sygnał różnicowy.

Aby przekanać się nausznie co to jest bit perfect należałoby wykonać prosty test, ale niestety wielu się nie chce albo wymigują się wymówkami o braku odpowiedniego sprzętu. Sprzęt do testu kosztuje mniej niż audiofilski kabel - myślę, że w 300 zł dałoby się zmieścić. 

Zewnętrzny sprzętowy dekoder sygnału AC3/DTS/HDCD potrzebuje na wejściu cyfrowym ciągu bitów. Ten ciąg bitów z odtwarzanego pliku MUSI być nienaruszony. Jeśli ciąg bitów zostanie poddany jakiejkolwiek manipulacji (np ściszenie w foobarze o 0,1 dB) to dekoder nie rozpozna sygnału w ogóle - dostaniemy w kolumnach szum. Nie muzykę ściszoną o jakąś wartość, ale ciągły szum.
Ten sprzętowy dekoder pracuje oczywiście na 24 bitach. Jakakolwiek manipulacja na przesyłanym sygnale spowoduje, że dla dekodera będzie to sygnał niezrozumiały.
I teraz jeśli w drodze testu nasz sprzetowy dekoder rozpoznaje sygnał i podaje muzykę to znaczy, że cała konfiguracja od pliku w odtwarzaczu programowym, poprzez wyjscie cyfrowe, kabel i wejście cyfrowe jest poprawnie ustawiona. Wypinamy wówczas sprzętowy dekoder i nic nie zmieniając w jego miejsce wstawiamy nasz ulubiony DAC.

Do takiego testu trzeba użyć specjalnie spreparowanego pliku wave* z ukrytą zawartością AC3. Tylko sprzetowy dekoder jest w stanie taki plik odczytać. Ten plik ma to do siebie, że niesie ukrytą zawartość. Ta ukryta zawartość może być rozpoznana przez zewnętrzny, sprzętowy dekoder TYLKO wówczas, kiedy nie zajdzie absolutnie żadna ingerencja w ciąg bitów - choćby owe ściszenie o 0,1 dB.
Po wypaleniu takiego pliku na płycie można też sprawdzic czy nasz odtwarzacz CD daje na wyjsciu cyfrowym sygnał zgodny bitowo czy też modyfikowany.

To co robi DAC po otrzymaniu ciagu bitów to już zupełnie inna para kaloszy. To już jest czysta fantazja twórców danego DACa. 
Przesył zgodny bitowo to jedno a to co robi DAC po otrzymaniu bitów to drugie. Jeżeli komuś zależy na przesyle zgodnym bitowo to niestety musi się pogodzić z pewnymi faktami a te są takie, że KAŻDA manipulacja na sygnale cyfrowym spowoduje utratę bitperfect.

--------------
* pisałem o tym

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

34 minuty temu, Funnykris napisał:

Tak w ogóle to często w DAC i tak następuje resampling więc... To całe bit Perfect to czysta teoria.

To nie jest teoria, to praktyka całkowicie mierzalna i co najciekawsze dająca się doskonale na ucho usłyszeć. 
Podczas testu na bitperfect albo usłyszysz szum albo dźwięk.
Wynik jest jednoznaczny:
- dźwięk = przesył bitperfect
- szum = przesył niezgodny bitowo

16 minut temu, negatyw napisał:

Dużo słów, a screenów nikomu się nie chce zapodać...

Przeczytaj dokładnie tę dużą ilość słów. Nie da się dać screenu. Trzeba zrobić test!

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 12 Maja 2023 przez yayacek

[negatyw]

Ja nie podważam Twojej wiedzy i praktyki. Sens jest dla mnie czytelny i zrozumiały.

Nie zaszkodzi jednak, gdy ktoś kto zada sobie trud i takie testy zrobi i stwierdzi, że brzmi to REWELACYJNIE - pochwali się screenami swoich ustawień.

Mam wrażenie, że puentą tych dyskusji jest: bitperfect nie istnieje...

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Funnykris]

2 godziny temu, yayacek napisał:

Nie istnieje pojęcie regulacji głośności w domenie bitperfect. To jest zaprzeczenie samo w sobie tak jak młody starzec.

Co nie zmienia faktu że dane nie zostały utracone. 

2 godziny temu, yayacek napisał:

Sumowanie w przeciwfazie pliku źródłowego i przechwyconego ciągu bitów na wyjsciu cyfrowym wyraźnie pokaże różnicę - zamiast cyfrowej ciszy dostaniesz sygnał różnicowy.

Wystarczy że wyrównamy głośność i będzie cisza jak makiem zasiał. To tylko dowodzi tego że dane nie zostały utracone i nie ma to wpływu na jakość muzyki. To jest cyfrowe audio. W tym przypadku bit Perfect nie ma kompletnie znaczenia. Możesz uważać inaczej ale upór świadczy tylko o głębokim niezrozumieniu tego jak działa zapis cyfrowy i co to jest rozpiętość dynamiczna/głębia bitowa. 

Cyfrowa regulacja głośności to obecnie najdoskonalsza metoda jaka jest. Nie rozumiem jak można negować tak prosty fakt. Sam jej nie używam poza telefonem ale nie neguję tego faktu. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[przemak]

26 minut temu, Funnykris napisał:

Wystarczy że wyrównamy głośność i będzie cisza jak makiem zasiał. To tylko dowodzi tego że dane nie zostały utracone i nie ma to wpływu na jakość muzyki. To jest cyfrowe audio. W tym przypadku bit Perfect nie ma kompletnie znaczenia. Możesz uważać inaczej ale upór świadczy tylko o głębokim niezrozumieniu tego jak działa zapis cyfrowy i co to jest rozpiętość dynamiczna/głębia bitowa. 

Nie. Będą różnice. Oczywiście one wystąpią w bitach niższych niż 16 czyli mogą zostać pominięte, ale przetwornik np 24 bitowy dostanie inny sygnał. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[Funnykris]

21 minut temu, przemak napisał:

Nie. Będą różnice. Oczywiście one wystąpią w bitach niższych niż 16 czyli mogą zostać pominięte, ale przetwornik np 24 bitowy dostanie inny sygnał. 

Jeżeli mowa o pliku 16 bit nie będzie żadnych różnic i to wynika z metodologii zapisu. Co innego gdybyś ściszał plik 24 bit na DAC 24 bit. Wtedy już tniesz. Ale teraz większość DAC ma już 32 bit.

Cała ta dyskusja nie ma sensu z takiego jednego prostego powodu. Nie ma praktycznie muzyki która skorzystałaby choćby ze standardów dynamicznych CD audio a co dopiero 24 bit. Zatem dla plików 24 bit nawet ucięcie tego jednego bitu nic nie zmieni w jakości dźwięku. To są gigantyczne różnice w potencjalnej głośności.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[przemak]

12 minut temu, Funnykris napisał:

Jeżeli mowa o pliku 16 bit nie będzie żadnych różnic i to wynika z metodologii zapisu.

Będą. Na ostatnim bicie, ale będą. A przy różnicach większych niż 48dB wejdą w szesnascie bitów. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[yayacek]

1 godzinę temu, Funnykris napisał:

Wystarczy że wyrównamy głośność i będzie cisza jak makiem zasiał.

To tak nie działa. Jak sobie zrobisz test na przesył bitperfect za pomocą pliku wave z zakodowaną informacją AC3 to się przekonasz. Po raz enty powtarzam, dekoder sprzetowy MUSI dostać ciąg bitów nienaruszony. Po ściszeniu choćby o 1 dB ciąg bitów ulega zniekształceniu i dekoder dostaje sygnał niezrozumiały = słyszymy szum. Możesz sobie teraz wyrównywać głośność w wzmacniaczu czy w dekoderze a i tak nie przywrócisz bitów do stanu oryginalnego. Ciągle będzie szum.
Ten szum świadczy o naruszeniu oryginalnego stanu bitów. Oryginalne dane zostały utracone na skutek manipulacji na ciągu bitów i żadne sztuczki po stronie odbiorczej nie przywrócą tego oryginalnego stanu.
Test z plikiem wave+zakodowana informacja AC3 jest o tyle ciekawy, że pokazuje od razu jak manipulacja na ciągu bitów wpływa na efekt końcowy. 
Uzyskując za pomocą tego testu przesył bit perfect można się od razu przekonać jak choćby najmniejsze ruszenie suwakiem głośności w odtwarzaczu programowym wpływa na sprzetowy dekoder. Spowoduje to natychmiastową utratę przesyłu zgodnego bitowo = szum zamiast dźwięków. Naruszonego ciągu bitów nie da się przywrócić po stronie odbiornika do stanu oryginalnego = ciągle będzie szum.
Bardziej obrazowo ale bardziej skomplikowanie można zrobić ten test za pomocą pliku HDCD ale potrzeba sprzętowego dekodera HDCD, które dość rzadko można spotkać. Tutaj przy przesyle bitperfect dekoder rozpozna sygnał (i np zapali stosowną diodę), a jeśli ciąg bitów zostanie naruszony diody nie zapali. I można sobie teraz dowolnie manipulować i klikać w cokolwiek na dekoderze HDCD a i tak nie spowoduje to rozpoznania sygnału - bo ciąg bitów został naruszony i dupa blada. 

Test na plik wave+zakodowana informacja AC3 jest także przydatny do zbadania odtwarzacza CD na okoliczność bit perfect. Może się okazać, że raptownie wiele odtwarzaczy CD (szczególnie dziwnych marek) wypuszcza na wyjściach cyfrowych sygnał niezgodny bitowo z zawartością płyty. Takiego niezgodnego bitowo sygnału nie można w jakikolwiek sposób przywrócić do stanu oryginalnego. Dekoder takiego sygnału nie rozpozna i wypluje szum zamiast tego, co jest w rzeczywistości zawarte na CD.

Ten sprzętowy dekoder AC3/DTS/HDCD należy potraktować jak miernik. To narzędzie w tym przypadku służące nie do słuchania a do pomiaru cyfrowej linii przesyłowej. On się nie myli i albo dostaje sygnał zgodny bitowo albo dostaje sygnał niezgodny bitowo - co od razu widać i słychać. Nie ma stanu pośredniego. Nie ma też możliwości ŻADNEJ z przesyłu niezgodnego bitowo zrobić zgodny kręcąc czymkolwiek na mierniku (dekoderze) czy w połączonym z nim wzmacniaczu.

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[danadam]

4 hours ago, Funnykris said:

Co nie zmienia faktu że dane nie zostały utracone.

Ja bym raczej powiedział: informacja nie została utracona. Dane zostały zmienione, ale dzięki temu, że informacja nie została utracona, dane mogą być zmienione z powrotem do pierwotnej postaci.

1 hour ago, yayacek said:

Oryginalne dane zostały utracone na skutek manipulacji na ciągu bitów i żadne sztuczki po stronie odbiorczej nie przywrócą tego oryginalnego stanu.

Dla zobrazowania o czym mówi @Funnykris, zaczynamy z plikiem 16-bitowym i ściszamy go w 24-bitach np. o 43.1415 dB (nie więcej niż 48 dB):

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

następnie pogłaśniamy o 43.1415 dB:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

i na końcu konwertujemy do 16-bitów (bez ditheringu oczywiście):

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Porównujemy pierwszy z ostatnim i okazuje się, że są co do bitu identyczne:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

(pliki w załączniku)

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[yayacek]

7 godzin temu, danadam napisał:

i na końcu konwertujemy do 16-bitów (bez ditheringu oczywiście):

To się zgadza - to oczywiste. Gdybyś nie konwertował do 16 bit to dostałbyś różnicę co też oczywiste.
Jednakże taką operację możesz zrobić tylko po stronie źródła kiedy dane nie wyjdą po kablu na zewnętrzny dekoder.
I teraz mamy sytuację z przesyłem bit perfect.
Ciąg bitów z pliku testowego (wave+zaszyta informacja AC3) opuszcza źródło i po kablu wchodzi do odbiornika. Jest bit perfect-> dekoder rozpoznaje sygnał i jest dźwięk zamiast szumu.
Ciąg bitów z pliku testowego (16 bit wave+zaszyta informacja AC3) po przykładowo ściszeniu o 0.1dB (czy jakakolwiek inna ingerencja) opuszcza źródło. To będzie ściszenie w rozdzielczości 24 bit. Do odbiornika dociera teraz zamiast oryginalnych danych ciąg danych zmodyfikowanych w rozdzielczości 24 bit. Nie jest bit perfect-> dekoder nie rozpoznaje sygnału i jest szum. Nie jest możliwe po stronie odbiornika podciągniecie głośności o wartość uprzednio zdjętą i tym bardziej przeprowadzenie w nim opcji redukcji bitowej w dół bez ditheringu by przywrócić sygnał do stanu oryginalnego. Bo skąd niby dekoder miałby wiedziec jaki był stan oryginalny po stronie źródła 😉 Nawet ręcznie tego się nie zrobi bo zamiast oryginalnych 16 bit doszło po kablu do odbiornika 24 bit. Dlatego odbiornik nie rozpozna pliku testowego i wypluje szum-> brak bitperfect.

Aby było prościej. Wypalasz plik testowy wave+zaszyta informacja AC3 na CD. To będzie wówczas zwykła płyta CD do odczytania na każdym odtwarzaczu CD/DVD.
Ciąg bitów wychodzi z wyjścia cyfrowego odtwarzacza CD i dociera do dekodera. Jeśli ciag bitów nie będzie naruszony to dekoder rozpozna sygnał-> bit perfect.
Jeśli natomiast odtwarzacz CD na wyjściu cyfrowym coś namiesza to na owym wyjściu cyfrowym dostaniemy oczywiście 16bit/44.1kHz (zgodnie z Red Book), ale będzie to zupełnie inne 16bit/44.1 niż zawarte na wypalonej płycie. Dane wyjściowe będą różne od danych wejściowych (czyli zapisanych na płycie). Dekoder nie rozpozna sygnału-> brak bitperfect i będzie szum. Co miałby zrobić dekoder by odzyskac informację utraconą na skutek złego wyjścia cyfrowego w odtwarzaczu CD? Ano nic, po pierwsze nie potrafi a po drugie skąd ma wiedzieć jakie operacje przeprowadzić.

Taki RME przykładowo dodaje do swojego produktu ADI-2 DAC FS (dość popularnego na forum) pliki testowe na okoliczność zbadania przesyłu bit perfect. Jak myślicie po co? - odpowiedź jest zawarta w instrukcji obsługi.
Można zbadać przesył po USB czy coax/optyk na okoliczność bitperfect. Kiedy przesył jest poprawnie skonfigurowany sprzętowo jak i programowo (bitperfect) ADI-2 podaje wynik na wyświetlaczu 'test passed'.
Jeśli test się nie powiedzie to choćbyśmy kręcili czymkolwiek na RME nie uzyskamy bitperfect bo dane po kablu doszły zmodyfikowane i RME nie będzie w stanie tych danych przywrócić do stanu oryginalnego.
W tym przypadku ten RME jest odpowiednikiem sprzętowego dekodera AC3 o którym ciągle wspominam. Zasada jest ta sama DANE wyjściowe muszą się równać DANYM wejściowym. Tutaj RME dokonuje testu na podstawie sumy kontrolnej a dekoder na podstawie ukrytego sygnału.
RME jest drogi a dekoder sprzętowy tani. Zarówno jeden jak i drugi sprawdzi przesył na okolicznośc bit perfect tak samo dobrze.
Link do instrukcji RME: 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[yayacek]

9 godzin temu, danadam napisał:

zaczynamy z plikiem 16-bitowym i ściszamy go w 24-bitach

Tak mi się jeszcze przypomniało.
Co znaczy ściszamy w 24 bitach?
Foobar przykładowo taką operację wykona w 32 bit a potem redukcja do 24 bit bez dithera - tak było kiedyś.
Teraz nie wiem ale prawdopodobnie obecnie foobar taką operację ściszenia wykona w 32 bit float (wersja 64 bit zrobi to w 64 bit float) a potem redukcja do 24 bit z ditherem i tak wypluje na wyjście.
Jriver operuje głośnością na 64 bit float z redukcją do 24 bit z ditherem, windows pracuje z regulacją głośności tez z ditherem.
Wszystkie normalne DAW przy tak banalnej operacji jak ściszenie wykonują te zadanie w 32 bit float z ditherem albo bez w zależności od ustawień użytkownika.

Poza tym nie o samą głośność chodzi. A co jeśli soft odtwarzający czy odtwarzacz CD dodaje dither na wyjściu do sygnału - różne są widzimisię pseudo konstruktorów szczególnie wśród tych tzw. audiofilskich. A co jeśli na skutek błędnej konstrukcji mamy problemy z polaryzacją na wyjściu cyfrowym? Albo w jakimś DVD zaszyte oprogramowanie w procesorze dodaje limiter na wyjściu cyfrowym albo co gorsza jakiś audiofilski odtwarzacz CD ma zaszyty equalizer na wyjściu cyfrowym?
Jak niby miałoby się przywrócić takie niedociągnięcia do stanu poprawnego po stronie odbiornika sygnału cyfrowego? Nie da się. 
Jak się dowiemy o takich manipulacjach - na słuch? Może stąd się potem biorą dyskusje o różnie grających transportach CD.
Dlatego właśnie przeprowadza się test na bit perfect by upewnić się, że ŻADNE manipulacje na danych nie zachodzą po stronie źródła i że na wyjściu cyfrowym dostajemy dane identyczne z tymi jakie są zapisane na CD. Jak mamy pewność, że dane idą 1:1 od źródła do odbiornika to potem możemy z tymi danymi otrzymanymi szaleć ile chcemy - przetwarzać je dowolnie, ściszać, zgłaśniać, manipulować, bawić się DSP itp jak to jest w przypadku RME.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 13 Maja 2023 przez yayacek

[fozzie]

10 godzin temu, danadam napisał:

Ja bym raczej powiedział: informacja nie została utracona. Dane zostały zmienione, ale dzięki temu, że informacja nie została utracona, dane mogą być zmienione z powrotem do pierwotnej postaci.

Dla zobrazowania o czym mówi @Funnykris, zaczynamy z plikiem 16-bitowym i ściszamy go w 24-bitach np. o 43.1415 dB (nie więcej niż 48 dB):

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

następnie pogłaśniamy o 43.1415 dB:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

i na końcu konwertujemy do 16-bitów (bez ditheringu oczywiście):

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Porównujemy pierwszy z ostatnim i okazuje się, że są co do bitu identyczne:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

(pliki w załączniku)

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Wszystko się zgadza, tylko gdzie tu jest ReplayGain, bo przypominam, że od tego się zaczęło.

  

W dniu 12.03.2023 o 17:32, Funnykris napisał:

Jakie to ma znaczenie w 24 bitach? Każdy współczesny DAC ma choć tyle.

  

W dniu 12.03.2023 o 18:05, Funnykris napisał:

Replay Gain to informacja o tym ile db trzeba odjąć czy dodać żeby osiągnąć założony cel średniej głośności utworu. Odtwarzacz to czyta i to stosuje. Przy wyjściu do DAC w 24 bitach obcinane są dodane zera no chyba że utwór jest w 24 bitach. Wtedy najlepiej by było mieć DAC 32 bit. Niemniej jednak dla 99% plików 16 bit RG nie ma wpływu na dane jakie trafiają do DAC. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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