Dnia Wed, 7 Nov 2012 08:42:59 +0000 (UTC), Adam Wysocki napisał(a):
Nie do wiary :) To musi być sfabrykowane :)
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 ;)
qPs. 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...
qW 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%
Have something to add? Share your thoughts — no account required.
Ask the community — no account required