Różnice w brzmieniu playerów pomimo transmisji bitperfect

[yayacek]

Od zawsze byłem twierdzenia, że playery softwarowe brzmią tak samo o ile zachowana jest transmisja bitperfect.
Moje niepokoje zaczęły się w momencie kiedy został wypuszczony Foobar 2.0/64bit - od razu poczułem, że coś jest nie tak jak było. Po uaktualnieniu do v2.0 wszystko zaczęło grac inaczej niż przedtem.
Sprawdzałem naście razy czy przesył bitperfect jest zachowany i oczywiście wszystko było OK -> vide

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) .
Bitpefect w Foobar 2.0 jest możliwy do uzyskania pod warunkiem odhaczenia kilku opcji. Oczywiście protokół ASIO jest zaprzęgnięty, więc wszelkie testy odbywały się za pośrednictwem ASIO.
Wpierw wmawiałem sobie, że to sugestia, potem szukałem innych rozwiązań typu różne wtyczki foobarowe do ASIO. 
Potem ściągnąłem inne playery - AIMP oraz MusicBee. Każdy gra inaczej pomimo bitperfect.
AIMP jest bitperfect o ile ustawi się w nim próbkowanie na sztywno czyli mamy plik 44.1kHz i musimy w AIMP ustawić w opcjach odtwarzania 44.1kHz. Kiedy potem włączymy plik np 96kHz to musimy przełączyć w AIMP próbkowanie na 96kHz - upierdliwe. Wynika to z faktu, że w AIMP jest zaaplikowany na stałe resampler, który nie jest aktywny tylko wówczas kiedy próbkowanie odtwarzanego pliku = próbkowanie ustawione w opcjach odtwarzania AIMPa
MusicBee zachowuje się poprawnie, ASIO działa w nim stabilnie i tak jak wyżej wspomniałem bitperfect jest pełną gębą.
Ale pomimo bitperfect pod ASIO każdy z tych odtwarzaczy brzmi kompletnie odmiennie. Foobar, AIMP, MusicBee, Foobar v1.6, Foobar v2.0/64bit - każdy brzmi inaczej, żaden z nich nie brzmi tak samo. Pięć odtwarzaczy i pięć różnych brzmień! Pokopałem w necie i okazuje się, że AIMP oraz MusicBee oparte są na bass audio library czyli na zupełnie innych fundamentach niż Foobar. Ponoć Winamp też był zbudowany w oparciu o bass library ale nie jestem pewien.
Aby wykluczyć omamy słuchowe przełączyłem się na zintegrowaną kartę dźwiękową - tu musiałem pod każdym programem posiłkować się ASIO4All. Karta zintegrowana a na niej wyjście cyfrowe (optyk) to najkrótsza droga by wypuścić audio z kompa. Windows zapewnia doskonałą integrację bo to jest część protokołu High Definition Audio i Windows sam zapewnia sterowniki do obsługi tej ścieżki.
Dalej to samo, każdy odtwarzacz brzmiał inaczej, pomimo (powtarzam ponownie) wielokrotnie sprawdzanej poprawności na transmisję bitperfect.
Mam w szafie stado przetworników D/A, więc pomyślałem, że ten którego używam (bo lubię najbardziej ze względu na brzmienie) obecnie jest za stary albo uszkodzony albo cholera wie co. Wpiąłem inny, potem jeszcze inny a potem wielki amplituner KD by SONY. Nic z tego, za każdym razem różnica pomiędzy odtwarzaczami była słyszalna.
Poddałem się i skupiłem się jedynie na Foobarze 1.6 vs 2.0/64bit - innych playerów i tak nie zamierzam używać (kwesta przyzwyczajenia). Cokolwiek bym nie zrobił i jakiegokolwiek DACa bym nie podpiął to zawsze jestem w stanie bezproblemowo wyłapać różnicę w brzmieniu. To nie jest jakiś niuans, to jest spora różnica w dynamice i tonalności.
Nie jestem w stanie sobie tego wytłumaczyć. Test na bitperfect przechodzą wzorowo, przechwycenie sygnału po cyfrze i potem sumowanie w przeciwfazie daje idealną ciszę cyfrową - czyli według fizyki/matematyki różnic nie ma. A jednak brzmi odmiennie.
Foobar 1.6 otwiera każdy plik w 32bit float a potem pcha go do małego programiku zwanego ASIO HOST (32 bit), z którym komunikuje się cyfrowe wyjście karty dźwiękowej.
W przypadku Foobar 2.0/64bit każdy plik otwierany jest w postaci 64 bit (float czy integer - nie mam pojęcia) a potem jest pchany do ASIO HOST (64 bit) a potem musi to zostać dostosowane do cyfrowego wyjścia karty dźwiękowej. A te zawsze pracuje pod ASIO w opcji 32 bit integer. Więc w przypadku Foobar 2.0/64 bit być może projektant coś namieszał i te konwersje pomiędzy 64 a 32 bit mu nie wyszły - choć zdaję sobie sprawę, że jest to dość głupie wyjaśnienie problemu.
Zasadniczo Foobar 2.0 to zupełnie inny odtwarzacz niż 1.6. Został niemal całkowicie przeprojektowany, dodano dodatkowe kodery, wywalono Direct Sound, wbudowano na stałe WASAPI, zaaplikowano dekodowanie odtwarzania wielokanałowego, zastosowano dodatkowy bufor dla WASAPI, dodano integrację z volume pod Windowsem - czyli takie bloatware, ale właściwie nie powinno mieć to wpływu na odtwarzanie.

Na forum Foobara ciężko się porozumieć. Twórca softu jest bardzo buńczuczny i wszelkie posty tyczące różnicy w brzmieniu są kasowane - sam miałem dwa takie przypadki. Odpowiedź jest zawsze taka sama - różnic nie ma. Gdzieś tam można znaleźć jakieś wpisy ale są one wyśmiane jako urojenia.
Ale aby było ciekawiej - mam cztery odtwarzacze CD marki SONY + jeden DVD też SONY. Nie jestem w stanie pomimo wielkiego wysiłku usznego wychwycić jakiejkolwiek różnicy pomiędzy nimi - oczywiście mowa o komunikacji odtwarzacz -> DAC. Wszystko zawsze łączę toslinkiem.

Zawsze twierdziłem, że kazdy odtwarzacz programowy brzmi tak samo - teraz twierdzę inaczej. Każdy brzmi odmiennie. Mimo bitperfect łatwo daje się wychwycić różnicę i Foobar v2.0 zupełnie nie brzmi dobrze. To jest zły dźwięk, kompletnie różny od dźwięku odtwarzacza CD Sony i kompletnie różny od Foobara 1.6. Nie jestem w stanie słuchać v2.0 bo mnie męczy i brzmi po prostu źle.

Oczywiście jestem w stanie zamieścić przechwycone sample z Foobara 1.6 i Foobara 2.0 ale myślę, że to trochę bez sensu. Przechwyt będzie obarczony podwójną konwersją D/A/D bo cyfra z karty -> DAC -> wyjście analogowe z DAC -> wejście analogowe do karty -> konwersja w karcie z analog na cyfrę. Różnica do wychwycenia będzie albo nie.
Jak ktoś chce sie pobawić to zalecam obok Foobara 2.0/64 bit postawić Foobara 1.6 (do ściągnięcia z oficjalnej strony) i sprawdzić samemu - nie pogryzą się.

Jestem skonfundowany, bo popełniłem na tym forum masę wpisów jakoby każdy odtwarzacz programowy grał tak samo. Ale teraz okazuje się, że nie miałem racji i niesłusznie wmawiałem innym, że się mylą. Z matematycznego punktu widzenia one grają tak samo - bit do bita identycznie. Ale kiedy te bity wchodzą na zewnętrzny przetwornik to dzieje się coś dziwnego i w zależności od programu odtwarzającego przetwornik gra zgoła odmiennie. Nie potrafię wyjaśnić tego zjawiska.
 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 19 Września przez yayacek

[gienas]

Przede wszystkim "bitperfect" to tylko określenie że plik na wejściu równa się plikowi na wyjściu. Cyfrowo.

Zawartosć cyfrowa pliku mówi jak odtwarzacz ma odtworzyć plik, cyfrowo.

Ale już po stronie analogowej tzn sama przeróbka pliku C/A jest wewnątrz procesora DAC - ale jak to juz wie tylko programista. I to wie też autor Foobara, bo kod chyba jest zamknięty. Nawet changelog Foobara nie mówi wszystkiego 🙂 .

Znaczy chcę powiedzieć że sam proces przemiany z cyfry na analog jest wewnątrz procesora DAC lub wewnątrz silnika odtwarzacza i tam zaglądnać nie można... A wszelkie aktualizacje wprowadzają zmiany.

 Tu bardziej skłaniałbym się do autosugestii, bo za dużo zmiennych na raz przyjąłeś.

 Ja słucham z maliny w stałych nastawach często tej samej muzy i teroretycznie muza brzmieć powinna identycznie. Ale i tak co jakiś czas "słyszę" te same kawałki inaczej... Co lepsze - słyszę fragmenty któych wcześniej nie słyszałem choć często go słucham...

 Fizjologia ucha działa.

Edytowane 19 Września przez gienas
literówka

[przemak]

Czy ten temat nie był już kiedyś omawiany? Rozwiązanie oidp też było... 

[yayacek]

8 minut temu, gienas napisał:

proces przemiany z cyfry na analog jest wewnątrz procesora DAC lub wewnątrz silnika odtwarzacza

Konwersja z cyfry na analog zachodzi zawsze w przetworniku cyfrowo-analogowym a nigdy wewnątrz silnika odtwarzacza, więc zasadniczo nie wiem co chciałeś napisać

13 minut temu, gienas napisał:

za dużo zmiennych na raz przyjąłeś

Zmiennych było bardzo mało. Zmieniały się tylko odtwarzacze programowe: Foobar 1.6, 2.0/64, MusicBee, Aimp.

17 minut temu, gienas napisał:

Przede wszystkim "bitperfect" to tylko określenie że plik na wejściu równa się plikowi na wyjściu. Cyfrowo.

Bitperfect to podstawa w transmisji cyfrowej. Bez bitperfect nie ma sensu rozważać jakichkolwiek zagwozdek. Bitperfect to pierwsza rzecz jaką należy sprawdzić i potwierdzić by przejść dalej do jakichkolwiek prób.
Bitperfect to określenie, że dane do DACa są przesłane zgodnie co do bita bez najmniejszej ingerencji w ciąg danych. Najmniejsza ingerencja w odtwarzany plik (nawet ściągnięcie volume o 0.01dB w odtwarzaczu) spowoduje utratę transmisji bitperfect.
To nie jest więc jakieś "tylko określenie" - to jest prawidło, jakie wpierw MUSI być spełnione by zająć się jakąkolwiek dalszą analizą. 
Proszę zapoznać się z linkiem w pierwszym poście.

1 minutę temu, przemak napisał:

Czy ten temat nie był już kiedyś omawiany? Rozwiązanie oidp też było... 

Omawiałem, ale wróciłem. Nie dawało mi spokoju. Wiem, że wówczas wrzucałem pliki z różnymi komponentami foobarowymi odpowiedzialnymi z protokół ASIO - oryginalny komponent ASIO vs nieautoryzowany komponent ASIO.
Pliki były różne pomimo transmisji bitperfect - sam je chyba oglądałeś. 

Kolego, nie pisałbym bzdur gdybym nie był pewny tego co się dzieje. Ja sobie dobrze zdaję sprawę, że mówienie jakoby różne odtwarzacze różnie brzmiały zakrawa na herezję. Ale tak do cholery jest i nie wiem jak to tłumaczyć.

Tu nie ma zbytniej filozofii.
Gra 1.6 a potem gra 2.0/64 bit. Ten sam DAC, te same utwory, przesył bitperfect a brzmi zgoła odmiennie.

[Pseudodrummer]

38 minut temu, yayacek napisał:

Gra 1.6 a potem gra 2.0/64 bit. Ten sam DAC, te same utwory, przesył bitperfect a brzmi zgoła odmiennie.

Może jest jakiś czynnik poza oprogramowaniem i sprzętem,który wpływa na percepcję?

[yayacek]

1 godzinę temu, Pseudodrummer napisał:

Może jest jakiś czynnik poza oprogramowaniem i sprzętem,który wpływa na percepcję?

Masz na myśli dopalacze? 🙂 Zapewniam, że testy dokonywane były na trzeźwo.

[Pseudodrummer]

4 minuty temu, yayacek napisał:

Masz na myśli dopalacze? 🙂 Zapewniam, że testy dokonywane były na trzeźwo.

Nie,nie to.
Skoro sprzętowo i programowo jest tak samo,a słychać różnice,może jest coś czego nie wziąłeś pod uwagę po prostu.

[gienas]

18 godzin temu, yayacek napisał:

Konwersja z cyfry na analog zachodzi zawsze w przetworniku cyfrowo-analogowym a nigdy wewnątrz silnika odtwarzacza, więc zasadniczo nie wiem co chciałeś napisać

Chciałem napisać - silnik odtwarzacza czyli czyli program zainstalowany w komputerze, natomiast pisząc procesor - miałem na myśli zewnętrzny DAC.

18 godzin temu, yayacek napisał:

Bitperfect to podstawa w transmisji cyfrowej. Bez bitperfect nie ma sensu rozważać jakichkolwiek zagwozdek. Bitperfect to pierwsza rzecz jaką należy sprawdzić i potwierdzić by przejść dalej do jakichkolwiek prób.
Bitperfect to określenie, że dane do DACa są przesłane zgodnie co do bita bez najmniejszej ingerencji w ciąg danych. Najmniejsza ingerencja w odtwarzany plik (nawet ściągnięcie volume o 0.01dB w odtwarzaczu) spowoduje utratę transmisji bitperfect.
To nie jest więc jakieś "tylko określenie" - to jest prawidło, jakie wpierw MUSI być spełnione by zająć się jakąkolwiek dalszą analizą. 
Proszę zapoznać się z linkiem w pierwszym poście.

Otóż przesył cyfrowy ZAWSZE jest 1:1 nie musisz tego sprawdzać.

Taki komunikat "bitperfect" na ekranie streamera moze się pojawiać kiedy tylko chcesz 🙂 i tylko programista streamera czy DAC-a wie na jakich zasadach.

 

Marketingowiec który wymyślił określenie "bitperfect" powinien dostać Nobla od branży.

Z mojej strony EoT.

[jar1]

O ile cyfra to cyfra i jest bitperfekt, to już fizyczny obraz sygnałów cyfrowych może być bardzo różny. W tym przypadku spdif.

 

[yayacek]

3 godziny temu, gienas napisał:

Z mojej strony EoT

Nie rozumiesz kolego zagadnienia i nawet nie zapoznałeś sie z linkiem jaki podałem odnośnie testowania transmisji bitperfect

3 godziny temu, gienas napisał:

Otóż przesył cyfrowy ZAWSZE jest 1:1 nie musisz tego sprawdzać.

Jeśli w odtwarzaczu programowym ruszysz np. suwakiem volume to przesył bitperfect nie będzie miał już miejsca. Ciąg bitów na wyjściu fizycznym będzie inny od ciągu bitów na wejściu do playera. Innymi słowy ciąg bitów przechwycony na fizycznym wyjściu cyfrowym po sumowaniu w przeciwfazie z plikiem odtwarzanym zamiast ciszy cyfrowej da sygnał róźnicowy a to swiadczy o błędzie w transmisji (brak bitperfect).

2 godziny temu, jar1 napisał:

fizyczny obraz sygnałów cyfrowych może być bardzo różny

Owszem, może. Ale w opisywanym przypadku gdzie mamy kilka playerów softwarowych i za każdym razem jest bitperfect ale inny dźwięk nie można tego tłumaczyć zmianą obrazu sygnału cyfrowego. Konfiguracja hardware'owa się nie zmienia - te same fizyczne wyjście, ten sam toslink, ten sam odbiornik.
Mamy kilka playerów softwarowych o potwierdzonym bitperfect i nie wyobrażam sobie by player (czyli sam soft) mógł mieć wpływ na (jak to nazwałeś) zmianę fizycznego obrazu sygnału. 

[msankowski]

Jeśli faktycznie strumienie są bit-perfect, konwerter jest ten sam, a jednak słychać różnicę po konwersji, to jedyną zmienną która może mieć wpływ jest czas, czyli jitter. Albo różna częstotliwość "próbkowania" DAC.

[jar1]

4 godziny temu, yayacek napisał:

Mamy kilka playerów softwarowych o potwierdzonym bitperfect i nie wyobrażam sobie by player (czyli sam soft) mógł mieć wpływ na (jak to nazwałeś) zmianę fizycznego obrazu sygnału. 

O, to może wystarczyć wystarczyć większe obciążenie softem procesorów obsługujących wymagane procesy. 

Im więcej potrzeba energii tym więcej również wszelkich śmieci i zakłóceń.  

 

W każdym razie jakaś różnica być musi, gdzieś. 

[yayacek]

W dniu 20.09.2024 o 00:09, Pseudodrummer napisał:

może jest coś czego nie wziąłeś pod uwagę po prostu.

Tak, jest coś.
To mi tak nie dawało spokoju, że przekopałem masę wpisów na forum foobara i znalazłem coś ciekawego.
Otóż jest/był błąd wychwycony przez pewnego użytkownika. Błąd polega na różnych formach zaokrąglania zmiennoprzecinkowego do 24 bit integer. Jak pisałem powyżej foobar otwiera każdy plik w 32 bit float (wersja 32 bit) lub 64 bit float (wersja 64 bit) - potwierdzone przez twórcę programu. Potem ten plik w wersji zmiennoprzecinkowej musi zostać przekonwertowany do wartości stałoprzecinkowej (integer) 16 bit albo 24 bit i tak zostaje wysłany na wyjście fizyczne. W przypadku ASIO jest to zawsze w kontenerze 32 bitowym.
I teraz w zależności od wersji Foobara (32/64) mamy różną formę zaokrąglania do wartości całkowitych (integer). 
W wersji 32 bit zaokrąglanie jest typu 'half to even' (w stronę zera) a w wersji 64 bit 'half away from zero' (w kierunku od zera).
Różnica wynika/wynikała z różnych metod optymalizacji działania CPU dla wersji 32 bit vs 64 bit.
Foobar 1.6 jest 32 bitowy, Foobar 2.0 jest 64 bitowy więc mamy tu dwie różne formy działania na liczbach zmiennoprzecinkowych wynikające z owego innego zaokrąglania. Różnice w formie zaokrąglania nie były zamierzone, po prostu się przytrafiły

Prześledziłem changelog i okazuje się, że w obecnej wersji 2.2 beta błąd wynikający z różnych metod zaokrąglania został wyeliminowany. Teraz nie pozostaje mi nic innego jak znów powtórzyć odsłuchy z wersją beta, gdzie błąd jest naprawiony.

Czyżby więc różnice w brzmieniach playerów software'owych brały się z min z różnych metod konwersji zmiennoprzecinkowej (float) do wartości całkowitych (integer)? Bo każdy player jaki znam zawsze otwiera każdy plik w formie 32 bit float/64 bit float a potem zachodzi konwersja do 16/24 bit integer. Tu jestem zbyt głupi by to rozkminić - ale jest to o tyle dziwne, że nie wpływa to na utratę transmisji bitperfect.
No i ta optymalizacja działania CPU. To dość tajemnicze jest jak dla mnie. Jak twierdzi twórca foobara, różne wersje Foobara (32/64bit) mają odmiennie zaimplementowaną ową optymalizację działania procesora głównego naszego komputera.

 

[Pseudodrummer]

15 minut temu, yayacek napisał:

Tak, jest coś.
To mi tak nie dawało spokoju, że przekopałem masę wpisów na forum foobara i znalazłem coś ciekawego.
Otóż jest/był błąd wychwycony przez pewnego użytkownika. Błąd polega na różnych formach zaokrąglania zmiennoprzecinkowego do 24 bit integer. Jak pisałem powyżej foobar otwiera każdy plik w 32 bit float (wersja 32 bit) lub 64 bit float (wersja 64 bit) - potwierdzone przez twórcę programu. Potem ten plik w wersji zmiennoprzecinkowej musi zostać przekonwertowany do wartości stałoprzecinkowej (integer) 16 bit albo 24 bit i tak zostaje wysłany na wyjście fizyczne. W przypadku ASIO jest to zawsze w kontenerze 32 bitowym.
I teraz w zależności od wersji Foobara (32/64) mamy różną formę zaokrąglania do wartości całkowitych (integer). 
W wersji 32 bit zaokrąglanie jest typu 'half to even' (w stronę zera) a w wersji 64 bit 'half away from zero' (w kierunku od zera).
Różnica wynika/wynikała z różnych metod optymalizacji działania CPU dla wersji 32 bit vs 64 bit.
Foobar 1.6 jest 32 bitowy, Foobar 2.0 jest 64 bitowy więc mamy tu dwie różne formy działania na liczbach zmiennoprzecinkowych wynikające z owego innego zaokrąglania. Różnice w formie zaokrąglania nie były zamierzone, po prostu się przytrafiły

Prześledziłem changelog i okazuje się, że w obecnej wersji 2.2 beta błąd wynikający z różnych metod zaokrąglania został wyeliminowany. Teraz nie pozostaje mi nic innego jak znów powtórzyć odsłuchy z wersją beta, gdzie błąd jest naprawiony.

Czyżby więc różnice w brzmieniach playerów software'owych brały się z min z różnych metod konwersji zmiennoprzecinkowej (float) do wartości całkowitych (integer)? Bo każdy player jaki znam zawsze otwiera każdy plik w formie 32 bit float/64 bit float a potem zachodzi konwersja do 16/24 bit integer. Tu jestem zbyt głupi by to rozkminić - ale jest to o tyle dziwne, że nie wpływa to na utratę transmisji bitperfect.
No i ta optymalizacja działania CPU. To dość tajemnicze jest jak dla mnie. Jak twierdzi twórca foobara, różne wersje Foobara (32/64bit) mają odmiennie zaimplementowaną ową optymalizację działania procesora głównego naszego komputera.

 

Twoja wiedza daleko przekracza moją,tu jestem zbyt głupi,by się odnieść.
Ale chętnie się czegoś nauczę..

[danadam]

Godzinę temu, yayacek napisał:

zaokrąglanie jest typu 'half to even' (w stronę zera)

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) to jest zaokrąglanie w stronę najbliższej liczby parzystej, czyli:

• 3.5 -> 4
• 4.5 -> 4
• 5.5 -> 6
• 6.5 -> 6

Godzinę temu, yayacek napisał:

Tu jestem zbyt głupi by to rozkminić - ale jest to o tyle dziwne, że nie wpływa to na utratę transmisji bitperfect.

Bo w konwersji integer -> float/double -> integer, jeśli ten float/double nie jest modyfikowany (brak zmiany głośności, brak eq), to nie ma czego zaokrąglać. Przykładowo:

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 21 Września przez danadam

[msankowski]

Konwersja konwersją. Jest bit-perfect na wyjściu, czy nie jest? Jeśli jest, to kierunek rozważań nie doprowadzi, moim zdaniem, do rozwiązania zagadki.

ASIO4ALL, karta zintegrowana, interakcja oprogramowania i sterowników 32/64bit, to jest terra incognita. Czy masz jakąś kartę z cyfrowym wyjściem audio, która ma porządny firmowy sterownik ASIO 64bit, którą możesz wysterować z foobar2000 64bit?

Przy okazji, dla użytkowników foobar2000, wczoraj odkryłem że została zaktualizowana wtyczka "DR meter". Działa z foobar2000 2.1 64bit.

[gienas]

15 godzin temu, yayacek napisał:

Ciąg bitów na wyjściu fizycznym będzie inny od ciągu bitów na wejściu do playera. Innymi słowy ciąg bitów przechwycony na fizycznym wyjściu cyfrowym po sumowaniu w przeciwfazie z plikiem odtwarzanym zamiast ciszy cyfrowej da sygnał róźnicowy a to swiadczy o błędzie w transmisji (brak bitperfect).

Mylisz pojęcia. Na wyjściu sygnał jest już analogowy i nie ma nic wspólnego z bitperfec.

Zmiany o których piszesz zachodzą po stronie analogowej. Sygnał w postaci cyfrowej nie odtworzy żaden DAC czy player. One go tylko przetwarzają na analogowy.

Może i o analogu masz pojęcie, ale już o cyfrowym pojęcia nie masz. A ja nie mam ochoty Cię uczyć...

 

[jar1]

9 godzin temu, yayacek napisał:

Czyżby więc różnice w brzmieniach playerów software'owych brały się z min z różnych metod konwersji zmiennoprzecinkowej (float) do wartości całkowitych (integer)? Bo każdy player jaki znam zawsze otwiera każdy plik w formie 32 bit float/64 bit float a potem zachodzi konwersja do 16/24 bit integer. Tu jestem zbyt głupi by to rozkminić - ale jest to o tyle dziwne, że nie wpływa to na utratę transmisji bitperfect.
No i ta optymalizacja działania CPU. To dość tajemnicze jest jak dla mnie. Jak twierdzi twórca foobara, różne wersje Foobara (32/64bit) mają odmiennie zaimplementowaną ową optymalizację działania procesora głównego naszego komputera.

Czegoś tu nie rozumiem. Czy to oznaczać też może, że mój przelew do banku tej samej kwoty zrobiony w systemie 32 bitowym i 64 bitowym mogą skutkować inną kwotą z powodu zaokrągleń systemowych? 😉

Konwersja gdzie trzeba coś dzielić, jak mi się wydaje, dotyczy sytuacji, gdy plik ten jest np. 24 bitowy a na wyjściu chcemy mieć 16 bit. Ty wiadomo, taka konwersja to starta informacji i nie ma co mówić o żadnym bit perfect.

Natomiast, jeśli plik mamy 16 bit i chcemy go przedstawić w strukturz2 24  to wystarczy do tych 16 bitów dopisać osiem  zer z przodu. I mamy dokładnie to samo.

Tak to się  chyba odbywa również w dac'ch, które działają jako 32 bitowe, niezależnie niezależnie czy dostają plik 16 bitowy czy 24 bitowy.

Czy może coś pomyliłem? 😉 

[gienas]

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

i grafika z tej samej strony

Czerwona linia to sygnał analogowy który słyszysz w głośnikach. Kratki to sygnał cyfrowy.

I tu właśnie zachodzi mylenie pojęć.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 21 Września przez gienas

[yayacek]

1 godzinę temu, msankowski napisał:

ASIO4ALL, karta zintegrowana, interakcja oprogramowania i sterowników 32/64bit, to jest terra incognita. Czy masz jakąś kartę z cyfrowym wyjściem audio, która ma porządny firmowy sterownik ASIO 64bit, którą możesz wysterować z foobar2000 64bit?

Przeczytaj dokładnie pierwszy wpis. Mam wszystko co potrzeba - użyta została karta dźwiękowa jak i zintegrowana. Powód takiego zachowania został podany we wpisie.

 

29 minut temu, jar1 napisał:

Natomiast, jeśli plik mamy 16 bit i chcemy go przedstawić w strukturz2 24  to wystarczy do tych 16 bitów dopisać osiem  zer z przodu. I mamy dokładnie to samo

Owszem, ale odtwarzacze programowe każdy plik otwierają w postaci 32bit float lub 64bit float - czyli jest to otwarcie pliku w postaci zmiennoprzecinkowej. Potem tak otwarty plik musi zostać zamieniony do postaci stałoprzecinkowej (integer) 16/24 bit. Tu był błąd - jak widać w changelog i jak wynika z forum foobara.
Jednak ten błąd nie powodował utraty transmisji bitperfect - co według mnie jest dziwne i nie potrafię tego zrozumieć.

53 minuty temu, gienas napisał:

ale już o cyfrowym pojęcia nie masz

Grzecznie proszę - zniknij kolego z tej dyskusji.

[jar1]

1 minutę temu, yayacek napisał:

Jednak ten błąd nie powodował utraty transmisji bitperfect - co według mnie jest dziwne i nie potrafię tego zrozumieć.

Transmisja to już etap kolejny, więc raczej nie ma tu nic do rzeczy. 

Porównywać należałoby pliki wyjściowego na samym wejściu (zanim soft cokolwiek zrobi) do pliku po transmisji, bit do bitu.

[yayacek]

2 minuty temu, jar1 napisał:

do pliku po transmisji, bit do bitu.

Test na bitperfect polega na przesłaniu sygnału testowego po łączu cyfrowym (coax/aoptyk) na zewnętrzny sprzętowy dekoder sygnału (dekoder sygnał rozpoznaje = jest bitperfect. Dekoder nie rozpoznaje sygnału = nie jest bitperfect)
albo
na przechwyceniu sygnału na fizycznym wyjściu cyfrowym, zarejestrowaniu go i porównaniu w przeciwfazie z odtwarzanym plikiem. Sumowanie da ciszę cyfrową = jest bitperfect. Sumowanie da sygnał różnicowy = nie jest bit perfect.

I tak właśnie był testowany każdy odtwarzacz softwarowy. Każdy przeszedł test na bitperfect poprawnie.
Każdy brzmi inaczej - i tu jest zagadka.
A jak nie wierzycie to najprościej jest postawić odtwarzacz MusicBee i posłuchać.

[przemak]

W dniu 19.09.2024 o 21:37, yayacek napisał:

Pliki były różne pomimo transmisji bitperfect - sam je chyba oglądałeś. 

OIDP to Twoje pliki były różne a moje takie same, a powodem były ustawienia playerów z różnymi dodatkami, których u mnie nie było.

Jeżeli mamy dwa identyczne strumienie, które brzmią różnie, to najczęściej odpowiedź jest prosta - operator error.

[gienas]

16 minut temu, yayacek napisał:

Grzecznie proszę - zniknij kolego z tej dyskusji.

Tak zrobię, pokonasz mnie.

[jar1]

20 minut temu, yayacek napisał:

Test na bitperfect polega na przesłaniu sygnału testowego

Pytanie jaki jest ten sygnał testowy. Jeśli coś podejrzewamy pod kątem konwersji w sofcie, to należałoby testować różne próbki testowe, z różnym gęstościami, by uwzględnić  jakoś działanie tych softwareowych konwersji.

[yayacek]

10 godzin temu, danadam napisał:

Bo w konwersji integer -> float/double -> integer, jeśli ten float/double nie jest modyfikowany (brak zmiany głośności, brak eq), to nie ma czego zaokrąglać. Przykładowo:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

A dlaczego wziąłeś akurat takie liczby?
Jeśli będzie

123 / 8388607 = 0.000014662744362681432089976321455993825911739577262351186555765456648523407998491287051592713784302924192300342595618080570468970593091320167937298767244668870528801742649286109123958244795590018700363481

i co wówczas? Jak zaokrąglisz do kilku liczb po przecinku to w zależności od metody zaokrąglania (half to even/half away from zero) dostaniesz inny wynik.
Więc albo czegoś nie rozumiem albo coś jest na rzeczy.
Jakby nie było changelog Foobara mówi, że błędy zaokrąglania zostały  wersji beta poprawione.
 

[danadam]

W dniu 21.09.2024 o 13:23, yayacek napisał:

Jeśli będzie

123 / 8388607

Jak będziemy dzielić przez 8'388'607 to dla najmniejszej możliwej 24-bitowej wartości, -8'388'608, wyjdzie nam -1.000000119..., czyli źle, bo chcemy w przedziale -1 do 1.

W dniu 21.09.2024 o 13:23, yayacek napisał:

= 0.000014662744362681432089976321455993825911739577262351186555765456648523407998491287051592713784302924192300342595618080570468970593091320167937298767244668870528801742649286109123958244795590018700363481

i co wówczas?

Akurat w komputerze wynikiem będzie 0.0000146627444... (jeśli mówimy o float 32-bit) bo to najbliższa liczba reprezentowalna w typie float:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

ale to bez znaczenia, bo i tak konwersja z powrotem będzie dokładna. Nietrudno jest sprawdzić sobie wszystkie możliwe 24-bitowe liczby:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Najbliższy współnczynnik skalowania przy którym będą błędy to:

• 8'387'159, wtedy np. z 128 powstaje 127.999992...
• 8'388'611, wtedy np. z 961195 powstaje 961195.0625

ale nawet w tych przypadkach to bez znaczenia, bo problem z "half to even" i "half away from zero" jest tylko wtedy jak dostaniemy dokładnie "cośtam.5".

W dniu 21.09.2024 o 13:23, yayacek napisał:

Jakby nie było changelog Foobara mówi, że błędy zaokrąglania zostały  wersji beta poprawione.

Nikt temu nie przeczy, na pewno nie ja. Można sobie nawet samemu potwierdzić. W załączniku są dwa pliki wav float32, jeden do konwersji do 16-bit, drugi do konwersji do 24-bit. Każdy zawiera tylko dwie próbki:

• w przypadku konwersji z zaokrąglaniem half-away-from-zero, w pliku wynikowym powinny powstać próbki o wartościach 1 i -1,
• w przypadku konwersji z zaokrąglaniem half-to-even, w pliku wynikowym powinny powstać próbki o wartości 0.

(W

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) pisali, że float->16bit używa half-to-even. Mnie tam wychodzi, że half-away-from-zero (przynajmniej w wersji 2.1.4))

Tak czy owak, ja tylko starałem się wyjaśnić dlaczego ta zmiana nie ma wpływu na transmisję bitperfect.

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ą ) Edytowane 23 Września przez danadam

[yayacek]

Nie poprzestałem i ciągle zgłębiam temat.
Od teraz definitywnie twierdzę, że różne playery grają różnie pomimo zachowania transmisji bitperfect.
Sprawa wydaje się jeszcze bardziej zagmatwana. Posłużę się Foobarem, który daje możliwość podpięcia zewnętrznego dekodera formatów.
Fabrycznie Foobar ma wbudowane wszystkie dekodery popularnych formatów typu flac, mp3, wave, aiff itd, itp. Są to dekodery oparte zdaje się na modyfikowanym przez twórcę ffmpeg.
Jest też możliwość wyłączenia tych wszystkich wbudowanych dekoderów (oprócz Cue Sheet Reader bo inaczej pliki cue nie będą rozpoznawane) i załączenie poprzez komponent

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) 'surowego' niemodyfikowanego dekodera ffmpeg. Po takim zabiegu wszystkie formaty audio będą dekodowane przez zewnętrzny niefoobarowy prawdziwy

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) . Bedzie to widać w konsoli foobara View -> Console w postaci ciągu -f w64 -acodec pcm_f32le czyli otwierany plik otrzymuje postać pcm 32 bit float.
I teraz ewidentnie jest różnica uszna pomiędzy odtwarzanym plikiem flac dekodowanym przez wbudowany foobarowy dekoder a tym samym plikiem flac dekodowanym przez zewnętrzny dekoder ffmpeg. Zawsze jest bitperfect - ciągle to będę podkreślał.
Ośmielam się tym samym twierdzić, że różnice w brzmieniu odtwarzaczy softwarowych biorą się z implementacji dekoderów i ich modyfikacji.
ffmpeg dekoduje wszystko, jest bardzo konfigurowalny i można zmieniać parametry dekodowania. Teraz od twórcy playera zależy jak ten ffmpeg zaadoptuje do swojego produktu.

Istnieje w foobarze opcja dodania komponentu umozliwiającego używanie wtyczek

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) . Można za pomocą tego komponentu podpiąć np. wtyczkę VST z miernikiem

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) . Używając wbudowanych w foobara fabrycznych dekoderów żadna pomiarowa wtyczka VST nie działa płynnie - ruch mierników nie jest płynny choć odczyty są poprawne. Na forum foobara pytając dlaczego mierniki VST nie działają płynnie otrzymałem odpowiedź, że foobar to nie DAW (stacja robocza) i zasadniczo się czepiam.
Stosując zewnętrzny dekoder ffmpeg mierniki VST działają wzorcowo.
Wskazuje to na fakt, że w przypadku fabrycznych wbudowanych dekoderów sygnał musi przechodzić przez cholera wie co (twórcy foobara nazywają to pipeline) co powoduje brak płynności w odczytach mierników VST.

Jest jednak jedna niedogodność - w przypadku stosowania zewnętrznego dekodera ffmpeg przewijanie wstecz wewnątrz odtwarzanego utworu nie jest płynne. Po przewinięciu np o 25 sekund w tył trzeba odczekać około pół sekundy zanim pojawi się dźwięk. Szybkie przewijanie w przód w obrębie utworu działa bez zarzutu. Ustawienie Buffer lenght w zakładce Preferences -> Output powyżej 4000ms powoduje brak gapless a w zakładce Preferences -> Advanced -> Buffering nie jest wskazane ustawienie wartości większej niż 2048kb w okienkach 'Read-ahead for local files' i 'Full file buffering up to'

Na obrazkach poniżej foobar z wyłączonymi wbudowanymi dekoderami + załączony zewnętrzny dekoder ffmpeg poprzez komponent

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) . Zewnętrzny dekoder ffmpeg pobieramy z githuba, zapisujemy na dysku w dowolnym folderze i następnie musimy podać ścieżkę do tego ffmpeg w okienku 'ffmpeg instalation folder'. U siebie pobrałem ffmpeg w wersji

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Najnowsza wersja z 2024 roku miała problemy otwieraniem m3u więc wziąłem coś starszego.

Jest z tym trochę zabawy konfiguracyjnej, ale nie jest to takie straszne.
Po całkowitej konfiguracji można łatwo przełączać się pomiędzy wbudowanymi dekoderami a prawdziwym dekoderem zewnętrznym. W tym celu należy jedynie odpowiednio ptaszkować wybór dekodera - na przykładzie flac będzie to:
 - flac dekoder wbudowany: odznaczyć FFmpeg Decoder Wrapper i zaznaczyć foobar2000 Flac Decoder
 - flac dekoder zewnętrzny: zaznaczyć FFmpeg Decoder Wrapper i odznaczyć foobar2000 Flac Decoder

 

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ą ) Edytowane 7 Października przez yayacek

[Ajothe]

Ciekawe! 

[jar1]

Ja tam wszędzie tam, czego używam wyłączam wszelkie konwersję. Ma być direct. 

Np. w BubbleUpnP można ffmeg wyłączyć.  Przecież ta konwersja jest użyteczna w przypadku, gdy nie dotyczy normalnych plików audio.