Audiofile...

Nov 07, 2012 179 Replies

Dnia Wed, 7 Nov 2012 08:42:59 +0000 (UTC), Adam Wysocki napisał(a):

Nie do wiary :) To musi być sfabrykowane :)

Ja jestem ciekaw co Pan Pacula wdycha :)

Alternatywnie - ile mu placa za pisanie takich tekstow ;)

q

Ps. O ile prze kablach sieciowych dajacych miesiste basy ;) mozna jeszcze dyskutowac, o tyle wmawianie ze kabel USB ma wplyw na dzwiek przesylany cyfrowo to zwykle oszustwo...

q

W dniu 2012-11-07 10:03, Jakub Jewuła pisze:

Na stronie była mowa o kablu LAN a nie USB. W przypadku USB i karty dźwiękowej przekłamania mogą się zdarzyć:

The USB Audio class uses the isochronous transfer type to stream audio across a USB link. Unlike other transfer types, isochronous transfers have no hardware-controlled handshaking or error-checking ability, so errors may occur occasionally.

Żadne krzyki i płacze nie przekonają ich, że czarne jest czarne...

U¿ytkownik "Adam Wysocki" snipped-for-privacy@somewhere.invalid napisa³ w wiadomo¶ci grup dyskusyjnych: snipped-for-privacy@news.chmurka.net...

"drgania w³asne kabla" - no zaje...

W dniu 2012-11-07 09:42, Adam Wysocki pisze:

Piękne jest to że ktoś potrafi na tym robić kasę.

W dniu 2012-11-07 09:42, Adam Wysocki pisze:

Ta wojna trwa nie od dzisiaj....

Teoretycznie mogę wyobrazić sobie tylko jedną sytuację w której zmiana kabla ethernet powoduje słyszalne zmiany w sprzęcie audio - zmiana kabla STP lub FTP na UTP bądź odwrotnie. Wzajemne połączenie masy audio, PE oraz zerowania lub uziemienia budynku może mieć nieprzewidywalne efekty ( nawet audio-wizualne ).

Pzdr

Adam Górski

Słyszalne zmiany powoduje _wiedza_ o fakcie zmiany kabla. Człowiek słyszy mózgiem a nie uszami.

Mówienie, że zmiana presetu w DSP nie wpływa na rejestrowany dźwięk, bo dokładnie takie same próbki docierają do niego z ADC (uszu) jest bez sensu ;)

Tzw. Inwazja Mocy - widowisko światło i dźwięk ;)

To faktycznie mo¿e tak dzia³aæ, ale potrafiê sobie te¿ wyobraziæ obiektywne problemy z d¼wiêkiem cyfrowym. Na przyk³ad w cyfrowej TV jak s± k³opoty z odbiorem to nie wiem dlaczego d¼wiêk zaczyna siê j±kaæ - powtarzaæ wielokrotnie ten sam kawa³ek (obraz tego nie robi, albo ja nie zauwa¿y³em). Mnie to znacznie bardziej przeszkadza, ni¿ gdyby wystêpowa³y chwile ciszy. Mo¿e przy odpowiednio d³ugim kablu USB, gdy poziom zak³óceñ utrudnia nad±¿enie z dos³aniem wszystkich danych na czas co¶ podobnego dzieje siê w mikroskali - nie s³ychaæ j±kania, a jedynie co¶ gorzej z d¼wiêkiem. S± te¿ w USB transmisje bez korekcji - równie¿ przy odpowiednio dobranym kablu mo¿na wprowadziæ do takiej transmisji pewien poziom b³êdów, który bêdzie odebrany jako pogorszenie jako¶ci d¼wiêku.

Ale to o czym piszê dotyczy sytuacji, ¿e dla wiêkszo¶ci jest OK a dla pewnych wyj±tkowych sytuacji jest ¼le, a nie ¿e dla wiêkszo¶ci jest ¼le a tylko dla pewnych specjalnych, japoñskich kabli jest dobrze. P.G.

W dniu 2012-11-07 09:42, Adam Wysocki pisze:

Na Zielonej Wyspie, trawa dla Baranów jest bardziej zielona niż gdzie indziej i wszystko jest możliwe. K.

Tak, dokładnie zaistniałe problemy mogłyby wystąpić w skrajnie trudnych warunkach ( problemy z transmisją ).

Nie mówimy tu o sytuacjach gdzie złocony kabel ethernet sprawia że basy są mięsiste a wierność dźwięku spada z 0,0001% do 0.000 nic.

Aż ciężko sobie wyobrazić żeby pojedyncze błędy na poziomie przesyłania pakietów nie dało się skorygować FEC-em lub retransmisją.

No chyba że wszystko leci w kablu na tzw "pałę" no ale wtedy nawet złoty kabel nie pomoże kiedy bufory odbiorcze puste są.

Adam

W dniu 2012-11-07 09:42, Adam Wysocki pisze:

NTG!

-> PL.REC.HUMOR

U¿ytkownik "Adam Wysocki" napisa³ w wiadomo¶ci grup

Piekne, piekne, ale gdzie szczegoly i lub pierwszy post ?

Bo w sieci oprocz FTP, TCP itp, jest jeszcze UDP.

Jesli urzadzenie najpierw sciaga plik, a potem odtwarza, to latwo mozna (o ile jest dostep do tych plikow) sciagnac je pare razy i porownac.

Jesli jednak jest to transmisja "dzwieku" przez UDP, to bledy zaczynaja byc istotne. A nawet przy TCP moze byc slyszalne jesli plik jest odtwarzany w trakcie sciagania i np zabraklo danych na czas.

Sumy kontrolne/CRC tez maja ograniczone zdolnosci wykrywania bledow, i moze sie przeslizgnac zepsuty pakiet ... aczkolwiek tu prawdopodobienstwo jest raczej znane i zbyt male :-)

W kazdym badz razie kabelek ktory wprowadza niewielka ilosc przeklaman to jest trudno zrobic, z reguly bedzie czysto, albo nic nie przejdzie :-)

P.S. Mialem kiedys ochote zripowac CD pare razy i porownac zawartosci, ale wtedy mnie skutecznie odstraszyl zmienny offset, czy jak to sie tam nazywalo. Ale teraz mozna by zrobic probe.

J.

Ale w transmisji gdzie nie ma czasu na powtórzenia często stosuje się kodowanie nadmiarowe - to po pierwsze.

Błędy w sygnale cyfrowym nie objawiają się szumami, czy innymi "soczystszymi dźwiękami" a losowym występowaniem skrzeków - to po drugie.

Wiesz jak zrobić połączenie sieciowe, które będzie działać, ale będzie miało dużą ilość błędów? Bo ja kiedyś próbowałem i nie szło.

Przecież CD-audio też ma kodowanie nadmiarowe, wprawdzie mniej dodatkowych bitów niż zwykła płyta z danymi, ale jednak...

ale a) stare urzadzenia, przynajmniej te stacjonarne, graly na biezaco i nie probowaly odczytac poraz drugi, b) przy sredniej ilosci uszkodzen kody korekcyjne nie wystarczaly i brakujace probki odtwarzano interpolujac sasiednie.

Tak czy inaczej taki test moglby przymknac usta zwolennikom zielonych pisakow czy zlotych plyt ... albo otworzyc ich przeciwnikom :-)

J.

Dnia 2012-11-07 09:42, Użytkownik Adam Wysocki napisał:

Gdzieś był link (chyba na tej grupie) do bezpiecznika 220V 630 mA z nieziemskiego stopu za 150 PLN. Audiofil też tam słyszy różnicę.

L.

W dniu 07.11.2012 19:49, Michoo pisze:

# tc qdisc change dev eth0 root netem loss 1%

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required