- Milyen TV-t vegyek?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- AMD GPU-k jövője - amit tudni vélünk
- Milyen cserélhető objektíves gépet?
- ThinkPad (NEM IdeaPad)
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Projektor topic
- Azonnali processzoros kérdések órája
- Lenovo Legion és IdeaPad Y széria
Hirdetés
-
Senua's Saga: Hellblade II - Íme a végleges gépigény
gp A folytatás megjelenéséig kicsivel több mint két hetet kell már csak várnunk.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Mindent megtudtunk az új Nokia 3210-ről
ma Részletes képek, specifikációk és euróban megadott ár is van a legendás modell újraélesztett verziójához.
Új hozzászólás Aktív témák
-
AMDFan
addikt
"Halkan jegyzem meg, hogy a jitter nem bithiba."
Olvasd el még egyszer a cikket. Én sem azt írtam, hogy a jitter=bithiba, hanem azt, hogy digitális átvitel esetén a jitter bithibát okozhat.
A többi részét nem kommentálom, ezeregy ilyen sztorit hallottam már. Vakteszten meg mindenki bukik, és könnyen belátható, hogy miért."a tesztelési metódika miért teljesen hibás"
Miért is? Előtted a lehetőség, hogy megcáfold amit írtam.
[ Szerkesztve ]
-
AMDFan
addikt
Más mi van akkor ha a nem legnagyobb biten csinálsz változást hanem csak egyel arrébb rakod az "1-est"?
Mert a jittler korrekció valós dolog és egy rossz olvasásánál (hibás/karcos cd) megpróbálja kitalálni mi lehetett ott és általában úgy van megírva hogy nem csinál ilyen pattogástSzándékosan a legnagyobb helyiértékű biten változtattam, mert az hallható. Minél kisebb helyiértékű biten történik hiba, annál kevésbé, vagy egyáltalán nem hallható a jelenség, de ha hallható, akkor mindig valamilyen anomáliát fogsz hallani, tehát pattanás, sercenés, ilyesmi. Ráadásul nagyon ritka az hogy USB Audio esetén bithiba lépjen fel, ha pedig tömegesen lép fel bithiba, rossz kábel vagy rossz csatlakozó miatt, akkor egy szakadozó hallgathatatlan valami lesz az eredmény.
AAC-t és OGG-t megnézem majd ha lesz időm. Ritka formátumoknak tűnnek számomra. De amúgy Te is megnézheted, az Audacity egy ingyenes és könnyen kezelhető szoftver
[ Szerkesztve ]
-
AMDFan
addikt
Kérlek mutasd meg ezt a vaktesztet. Ha valaha életedben vetted volna a fáradtságot és megcsináltál volna egyetlen egy ilyen vaktesztet is, akkor nem írnál ilyen dolgokat. De nem tetted. A cikkben ott vannak a tesztzenék és a szoftver amivel magad is meggyőződhetsz a leírtakról, csak ehhez rá kellene szánnod az időt. Az írásod amúgy kontraproduktív, mert pont, hogy a Te hifista önérzeted sérti az, hogy el kellene fogadnod, hogy amit hallassz azt valójában nem hallod, csak úgy hiszed, hogy hallod. Sajnos ez van. Kicsit olyan ez, hogy azért nem mernek a hifisták vaktesztelni, mert lerombolná a világképüket. Vagy olyan mint amikor az ember nem akar elmenni orvoshoz, inkább a boldog tudatlanságot választja.
-
AMDFan
addikt
Ne haragudj de olvasd el a cikket még egyszer. Az időbeliség digitális átvitel esetén nem akkora probléma. Ha hiba van, bithiba keletkezik. A D/A konverziónál mintavételezés közben előfordulhat jitter, ez az analóg jelben okoz problémát. A jitter egy összefoglaló elnevezés, ne mosd össze a különböző átvitelek vagy konverziók esetén fellépő jittert, mert nem ugyanarról van szó és a hatásuk sem ugyanaz.
(#48) arn: az látszik hogy nem vagy a szakértője, de el sem olvasod amiről itt eszemecsere folyna. A DAC puffereli a csomagokat. Tehát nem számít az hogy a digitális oldalon milyen időbeliséggel érkeznek a csomagok.
[ Szerkesztve ]
-
AMDFan
addikt
Akkor nézzük elméletileg a válaszokat:
"miert van elteres ket bitperfect lejatszo kozott?"
Más a felépítése, más az analóg elektronikája, más elektronikákon folyik át a jel a D/A konverzió után.
"miert szol mashogy ket os?"
Ezért találták ki az ASIO-t, az egy standard driver. Elméletben az OS belenyúlhat a digitális adatfolyamba és olyan "effektet" vagy szűrőt vagy algoritmust futtat rajta végig amilyet csak szeretne.
"miert szol mashogy ket usb kimenet?"
Nem értem a kérdést. Mi az hogy két USB kimenet? Ugyanazon a gép két USB kimenet máshogy szól? Ne vicceljünk...
"miert befolyasolja a tapellatas az usbkimenetek minoseget?"
Ez nem elméleti dolog, ha nincs szűrve az USB betáp a DAC előtt vagy a DAC-ban, akkor nagyon komoly alapzajt tud okozni ami sistergés formájában hallható a hangfalakon. De nem lesz tőle vékonyabb a basszusgitár
"miert szol mashogy ket usb kabel?"
Lásd fentebb. Lehet zajos egy USB. Ezen kívül pedig nem szól másképp.
[ Szerkesztve ]
-
AMDFan
addikt
nézd. ezek a dolgok nem léteznek. az, hogy egy rpi jobban szól mint egy PC... ugyan már azon kívül, hogy nem x86 hanem arm architektúra éppugyanazokkal a protokollokkal kommunikál. ezek képzelgések amiket leírsz. ami sokkal fontosabb, hogy egy rpi hangtalanul működik, míg egy PC-ben legalább egy tápventi zajt kelt a szobában. ennek sokkal nagyobb a jelentősége mint annak, hogy milyen OS fut a gépen. amúgy kiherélt linuxot felrakhatsz PC-re is, na nem mintha az armbian vagy akármelyik arm-es disztró az kiherélt linux lenne. ráadásul jóval gyengébbek ezek a hardware-ek mint egy normális PC.
-
AMDFan
addikt
válasz bujdosomark #66 üzenetére
Szia!
Nekem is volt eltérés a két szám között. Pont erről szól a cikk. Ha megnézed a második oldalon a legalsó képet, ott látszik, hogy van differencia az mp3 és a flac között, kb a 20-800Hz közötti spektrumban, ami az első 10 másodpercben 78dB peakkel van jelen. Azért az első 10 másodpercet választottam ki, mert itt volt a legkönnyebben tettenérhető a rosszul tömörített mp3 tömörítési hibája. Bárki megcsinálhatja magának ezeket a teszteket, ahogy te is tetted, nézze meg hol a legnagyobb a különbség az mp3 és a flac között, és hallgassa meg ABX teszterrel. Rengeteget lehet tanulni belőle. Azt mondjuk nem értem, hogy honnan vetted azt, hogy én nem találtam mérhető különbséget a flac és mp3 között. Hiszen az első oldalon már úgy kezdtem, hogy mérhető különbség van a két formátum között. Más kérdés, hogy ez hallható-e.szerk: én rengeteget szórakoztam már 320-as mp3 vs flac ABX tesztelésével. Néhány eléggé ritka esetben sikerült vakteszten 10-ből 10x megmondanom melyik az mp3, melyik a flac. Ezek a tömörítési hibák egyik esetben sem nyomták rá a bélyegüket a zenei élvezetre, nem lett tőle rosszabb a zene, nem lett tőle kevésbé élvezhető. Százalékban nehezen kifejezhető, hogy mennyivel többet számít mondjuk a szobaakusztika, vagy a hangfalaink elhelyezése mint az, hogy mp3-at vagy flac-et hallgatunk-e.
[ Szerkesztve ]
-
AMDFan
addikt
Érdekes. Én amúgy bármikor bárkivel szívesen találkozom aki tudja demozni nekem ezeket a jelenségeket, természetesen vakteszt keretein belül. Én kicserélem 10x az USB kábelt (vagy visszakötöm ugyanazt) és a hallgató megpróbálja eltalálni, hogy éppen melyik van bekötve. Aki vállalkozna erre, nyugodtan szóljon. Valamiért ilyen esetekben minden ember meghátrál és nem vállalkozik vaktesztre. Kb 10 éve ez a mantra megy. Mindenki hallja, de vaktesztre senki soha nem vállalkozik.
-
AMDFan
addikt
válasz bujdosomark #66 üzenetére
Bocs, lehet, hogy nem voltam egyértelmű. Természetesen nekem is hallható a különbség, ha a különbségfilet játszom le. Ez egyértelműen látszik a spektrumból is. Az, hogy nem hallható, arra értem, hogy ha lejátszod a két filet, nem fogod tudni azonosítani vakteszten, hogy melyik melyik.
[ Szerkesztve ]
-
AMDFan
addikt
Köszönöm!
Azt azért tegyük hozzá, hogy Te arról írsz főleg, hogy az analóg kimeneten mi mérhető D/A konverzió után.
A cikk pedig főleg arról szól, hogy D/A konverzió előtt mi történhet a hanggal. Azt én is megpróbáltam a cikkben egyértelművé tenni, hogy a digitális transzport esetén fellépő jittert ne keverjük a D/A konverziókor fellépő jitterrel, ezt egy képpel is megpróbáltam nyomatékosítani. Egyébként nagyon szívesen veszem azt infóidat arról, hogy a D/A konverzió utáni mintavételezési jittert mit tesz a zenével, mert mint ahogy írtam ehhez nem volt eszközöm tesztelni."Ezt bithibakereséssel nem mutatod ki."
Amit írtam arra vonakozott, hogy HA bithibák keletkeznek az átvitel során, akkor úgy keletkezik a hiba, ahogy a tesztfileokon is hallható. Pattogás például.
[ Szerkesztve ]
-
AMDFan
addikt
válasz bujdosomark #94 üzenetére
Ez valóban úgy van ahogy dabadab írja. Az Audacity az adott mintán lévő diszkrét 16 bites értéket mutatja, ami a PCM adatfolyamban van. Ez minél nagyobb frekvenciáról van szó, annál inkább csúnyán néz ki, de a Shannon–Nyquist-féle mintavételezési tétel értelmében a 20Khz szinusz még pontosan visszaállítható ennyi mintából is. Ezért használunk ugye 44,1Khz-es mintavételezést.
-
AMDFan
addikt
"Csomagújraküldést okozhat, ami meg fáziszajt okoz, és ez mehet át."
Én az USB audio protokollt nézegetve azt olvastam, hogy ott abszolút nincs csomagújraküldés. De egyébként, ahogy írtam nagyon ritka dolog az, hogy bithiba keletkezik. Csomagújraküldést egyébként kiválóan lehet mérni TCP/IP hálózatokon, ahol a 30 méteres filléres UTP kábelen is, elképesztően ritka a hibás csomagok száma. Pedig ott is ugyanúgy létezik a jitter jelensége, és ugyanolyan olcsó órajelgenerátorok vannak (alaplapi).
"lyen nincs, csak digitális oldalon értelmezett a jitter."
Ezt nem értem, miért ne lenne? A digitális-digitális átvitelnél van egy jitter, ezek után tegyük fel 1ms adat bekerül a DAC pufferébe (itt nincs időtényező hiszen az adat tárolva van a pufferben, várakozik), amit a D/A konverziónál szépen kiszed a DAC és újramintavételez.
-
AMDFan
addikt
"Érdekelne, hogy ezt tényleg hallottad-e."
Ezt te is hallhatod, ha letöltöd az első oldalon linkelt tesztadatot. A két 10 másodperces felvétel között pontosan 1 bitben van különbség. Az eredmény markánsan hallható.
"Ez tényleg így van! De az USB-n mi megy?"
Többféle adatfolyamot tud kezelni a protocol az egyik ezek közül maga a PCM. De itt a teljes specifikáció: [link]
[ Szerkesztve ]
-
AMDFan
addikt
"Két kábellel teszteltem:
Az egyik egy 800Ft-os Hama, a másik egy 3000Ft-os Kácsa.
A különbséget durván lehetett hallani, mert az egyiknél rendben volt a hang, a másiknál visszhangzott."Röviden, itt az egyiket úgy hívják, hogy rossz kábel
Amúgy simán lehet, hogy nem 75 ohmos kábelt adtak el neked az említett boltban, és a te rendszered szeretett volna a szabványban meghatározott módon működni. Ha már Te hoztad fel, elmondom, hogy a cikkben említett Ethernet kábeles eset is velük esett meg. Ethernet kábelt eladni százszoros áron egyébként már a pofátlanság kategóriáján is jóval túlmutat... Egyszerű átverés, simlisség. -
AMDFan
addikt
Sok dolgot kipróbáltam a valóságban. IT-val foglalkozom, rengeteg dolgot megnéztem már, egyidejűleg van otthon ARM alapú gépem armbiannal, van Macbookom OSX-el, az asztali gépem sima intel procis Ubuntu linuxal, és egy korábbi laptopom Windows-al. Voltak PCI-os, és USB-s hangkártyáim is, volt csak koax bemenetes interface-em is, firewire-ös is, bla bla nem sorolnám. Nem folynék bele személyeskedésbe.
Daphile-t egyébként nem ismertem eddig, de meg fogom nézni mit tud, mivel szakmai ártalom miatt az átlagnál kicsit mélyebben értek a linuxhoz. Látatlanban azt mondom, hogy semmi olyat nem tud amit egy ubuntu ne tudna, vagy bármely más disztró ami open source alapokon nyugszik.
(#109) Polllen: nem beszélgettem még denevérekkel
[ Szerkesztve ]
-
AMDFan
addikt
Bocs, a szóhasználat miatt miatt azt gondoltam, hogy ez ilyen kioktató modor akar lenni.
Amit leírsz az is egy tipikusan felmerülő kérdéskör. "Miért van az hogy nem is tudja, hogy történt valami, de másképp szól".
Mondom nagyon szívesen bennevagyok egy vaktesztben, nincs is ennél egyszerűbb dolog, kell hozzá két laptop, egyik Windows másik Daphile és lejátszani ugyanazt. Sőt most hogy belegondolok van egy Win10-em virtualbox alatt, megnézem mennyivel szól másképpen mint a linux. Még PCI passthrough is van tehát natívan a Windows fogja kezelni a DAC-ot.
Hozzáteszem, elméleti síkon, az operációs rendszer olyan szűrőt ereszt végig a PCM adatfolyamon amilyet csak akar, hiszen a lejátszószoftver az oprendszer libjeit, dll-jeit használja (kivéve ASIO és tsi.), magát a hangeszközt az oprendszer kezeli. Tehát elméletileg nagyon könnyen szólhat másként két oprendszer. Fel is merült bennem korábban az üzleti lehetőség ebben, engedjünk rá valamilyen effektet a PCM adatfolyamra, és adjunk ki egy dobozos terméket amin ez az Oprendszer fut. Csak lehet, hogy a tükörbenézés nehezebben menne utána.[ Szerkesztve ]
-
AMDFan
addikt
Igen, kérlek írd le hol. De ha van mondjuk 15 perced az életedből azért kipróbálhatnád ezt az ABX testerrel is amit szintén linkeltem a cikkben. Lehet hogy meglepődnél, hogy akkor már mégsem tudnád megmondani melyik melyik... Hogy az árakról beszéljünk, az én fülesem 250 ezer és nem hallottam a különbséget...
[ Szerkesztve ]
-
AMDFan
addikt
válasz #71562240 #131 üzenetére
Ilyen az amikor egy bölcsész áltudományos okoskodással próbál feltűnni. Amit írtál annak se eleje se vége. Ha egy kicsit is ismernéd a digitális jelfeldolgozást akkor nem írnál le ekkora butaságokat. Akármennyire is nem tetszik, nálunk sokkal okosabb emberek tökéletesítették a digitalizálást. Persze tudom Harry Nyquist és Claude Shannon csak valami kóklerek lehettek. Nevetségessé tetted magad már évekkel ezelőtt is amikor nem voltál képes elfogadni, hogy a TCP/IP protokoll tökéletes adatávitelt biztosít, erre most ezt megint felhozod. Bölcsebb maradtál volna ha nem kommentelsz.
(#133) kammerer: Szerk.: A hifi termékeket egyelőre alapvetően próba-szerencse alapon fejlesztik.
Te nem vagy semmi
[ Szerkesztve ]
-
AMDFan
addikt
Te tudod hogy mi az a TCP/IP protokoll? Mi köze van ennek ahhoz, hogy hány dB az analóg zaj egy RJ45 csatlakozónál? Komolyan mondom ez olyan mintha gyerekekkel vitatkoznék. Nézzél már utána a dolgoknak mielőtt lejáratod magad. A TCP/IP protokoll tökéletes adatátvitelt biztosít, a Cirrus Logic pedig arról ír, hogy vannak nehézségeik az EMI-vel. Biztos van, okoz problémákat, és? Ettől a számítógépes hálózatok tökéletes működnek, tökéletes adatátvitellel, erre szolgálnak ezek az átviteli protokollok, algoritmusok. Aki ezt nem látja be, azzal kár vitatkozni, mert nem tudja miről beszél.
Példa, nem CL hanem intel chipset:
RX packets:19161478894 errors:0 dropped:0 overruns:0 frame:0
TX packets:54624640465 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3730861448455 (3.3 TiB) TX bytes:74825073211927 (68.0 TiB)71 TiB forgalom nulla darab hibás csomag, a tökéletes hibajavítás miatt.
Köszöntem szépen.[ Szerkesztve ]
-
AMDFan
addikt
válasz #90088192 #143 üzenetére
Így van. HDMI-ről annyit, hogy nekem volt egyszer egy 15 méteres HDMI kábelem, ami bizonyos eszközök között nem volt tökéletes. Tudod, hogy jelentkezett a hiba?
Kicsit fakóbbak voltak a színek, nem volt olyan éles a kép sem...Viccelek. Több tízezer piros pötty mozgott ide oda a képen, elég nehéz volt nem észrevenni, hogy valami nem kóser. Na hát pont ilyen hibajelenséget produkál a nem tökéletes digit átvitel audio esetén is. -
AMDFan
addikt
Nézd. Amit írsz, előfordul, de könyörgöm olvasd már el itt a topikot. Amiről te beszélsz, hogy CRC is stimmel, meg az adat is átment és mégis hibás adat, az teszem azt 1 millió tebibyteonként egyszer fordul elő mondjuk, de szerintem sokkal ritkábban. Amit írsz nem fogja megérteni az aki arra hivatkozik, hogy ő hallja a két ethernet kábel közti különbséget a zenében. Remélem érted mire akarok kilyukadni.
(#160) bambano: igen ez így van. ehhez elő kell fordulnia annak, hogy pontosan úgy lesz hibás egy átvitel, hogy a checksum ugyanaz marad mint ami az eredeti csomag esetén is volt. ezt életszerűnek gondolod egy zeneszám hallgatása esetén? És továbbra is, a topik nem erről szól, hanem a digitális hibák megjelenéséről az analóg kimeneten.
[ Szerkesztve ]
-
AMDFan
addikt
"nekem párszáz gigánál már előfordult, nem is egyszer."
Ugyanarról a gépről beszélünk? Könnyen lehet hogy memóriahibás.
Párszáz gigánál előfordult, nem is egyszer? És azt gondolod, hogy ha párszáz gigánként néha hibázik a protokoll, akkor az egy konstans hallható problémát okoz a zenében? Most ugye viccelsz? Pláne ha mp3-ról beszélünk, pláne úgy hogy a cikkem rámutat arra, hogy a bithiba jelensége hogyan néz ki analóg formában, márpedig ha a TCP/IP-n hibás adat megy át az bithiba lesz, gondolom ezzel nem vitatkozol. -
AMDFan
addikt
válasz #71562240 #184 üzenetére
Jajj bocsánat, nem fogalmaztam egyértelműen. Nem a személyeskedésben nem süllyedek le a szintedre, mert azt valóban megtettem, miután ostobaságot írtál, emiatt elnézést, ez valóban az én jellemhibám, vagy ilyesmi.
A szakmai szintedre gondoltam. Na odáig nem süllyedek le, hogy vitatkozzak veled olyan alapvető szakmai kérdésekben amikre te valami elvarázsolt misztikus válaszokat képzelsz be, az amúgy 100%-ig egzakt válaszok helyett. Én meg nap mint nap ezzel foglalkozom hiszem ez a szakmám. Neked gyanítom nem ez, el sem tudom képzelni miért
Nem félsz hogy a banknál vezetett számládról egyszercsak eltűnik a lóvé, mert bithibás lesz az utalás, miután a CRC megtévesztette önmagát
Szánalmas...
[ Szerkesztve ]
-
AMDFan
addikt
Most már csak a saját szórakoztatásom végett, kiemelném a topik gyöngyszemét, kammerer hozzászólásából
Igazság szerint ez már tragikomikus, így pár órával a döbbenet után most már nevetni is tudok rajta.
"Vagy a cikk témája szerint is visszakanyarodva mondandómhoz, a méréseink tökéletlenségéhez, hiányosságaihoz, gyakorlati megfontolásaihoz. Vegyünk egy úgynevezett "veszteségmentes" tömörítést, mint a például FLAC. Például, ha egy WAV-fájlt betömörítek FLAC-ba, majd abból visszafejtek WAV-ba, a szokásos "mérőeszközeink" szerint ugyebár két "bitazonos" WAV-fájlom lesz. A FLAC elég ügyes, egy ilyen en- és dekódolás után nyilván nagyon kevesen tudják megkülönböztetni a két "bitazonos" WAV-fájl hangzásbeli eltéréseit. Ha tízszer megcsináljuk az oda-visszakódolást, már markánsabb lesz a különbség az első és a tizedik "bitazonos" WAV-fájl között. Ha hússzor, ötvenszer, százszor megcsináljuk, a "bitazonos" végeredmények hangzáskülönbségeit egyre többen és egyre nagyobb biztonsággal fogják tudni megállapítani akár vaktesztben is. Ugyebár, még a századik WAV-fájl is "bitazonos" lesz az elsővel (bár ez már nem biztos, de vegyük ezt az esetet), mégis már elég nagy hangzáskülönbségeket mutat fel. Aztán előbb-utóbb elérünk oda, hogy a sokadik visszakódolmány már nem lesz a "mérőműszereink" szerint sem "bitazonos". Aztán előbb-utóbb elérünk oda, hogy a sok-sok-sokadik visszakódolmány már lejátszható sem lesz. Mert bármely hibaellenőrzés többé-kevésbé "szúrópróbaszerű", bármely hibajavítás többé-kevésbé sztochasztikus, a legfejlettebb is, merthogy az adatba épített redundancia véges. Amíg véges a redundancia, addig elvileg nincs tökéletes adatátvitel, aztán, hogy a gyakorlatban mekkora eséllyel és mennyire "tökéletes", az a praktikus húzd meg ereszd meg módszerrel működik. Lásd, gyakorlati példák."
A lényeg ugye az, hogy ha párszázszor átkonvertálunk egy filet wav-ból flac-ba meg vissza akkor előfordulhat, hogy az már lejátszható sem lesz! Zseniális
-
AMDFan
addikt
Nézd, én nem kétszázezret hanem bármennyit feltennék erre ha bárki fogadna velem 1 az 1 millióhoz fogadást lehet kötni nálam
Komolyan gondolkoztam azon amúgy, hogy feldobom publikusan, hogy 50.000 Ft-ot fizetek annak aki előttem vakteszten megmondja a gyári USB-m és a 100 ezres kácsa kábel közti különbséget, csak nem tudom mennyire illendő ilyet csinálniAki meg két UTP között különbséget talál hangban annak én is 200 ezret fizetek. dabadab beszállsz te is? Akkor már 400 ezer ütné a markát az aranyfülü fórumtársnak
[ Szerkesztve ]
-
AMDFan
addikt
válasz #90088192 #213 üzenetére
Teljesen igazad van. Én gyakorlatias vagyok, adatközpontokat üzemeltetek, olyan adatforgalommal amihez képest egy zeneszám csepp a tengerben. Ilyen forgalom mellett mi igen igen ritkán (évente egyszer mondjuk) találkozunk corrupt adattal. Ez ugye köszönhető annak is, hogy már nem 56k modemmel vannak összekötve a rendszerek, hanem minimum 10Gbit ethernettel, vagy optikával. Teljesen más dimenzióban mozog már a számítástechnika mint mondjuk 20 évvel ezelőtt. Az, hogy a telefon ma többszörös teljesítményt tud (kb 20x) mint 20 évvel ezelőtt a számítógépem, az az IT más területein is megjelenik. Sok hifista viszont egy analóg dinoszaurusz a digitális világban, ezért is hiheti azt, hogy digitális másolással romlik a minőség. Ez egy tipikus "analóg" gondolkozás, édesapámnak is hiába magyarázom, hogy mi a különbség nem igazán érti. De ő mondjuk nem is okoskodik a témában
[ Szerkesztve ]
-
AMDFan
addikt
válasz #71562240 #217 üzenetére
"Lásd mint fent, hogy többé-kevésbé mit jelent a hibajavítás. Amikor egy betűt vagy számjegyet leíró bitcsomag hibás bitjét kell helyettesíteni, azt ugye elég könnyű eltalálnia a hibajavító algoritmusnak - ritkán romlanak el. Amikor egy digitális kép pixeleit leíró bitcsomagok bitjeit kell extrapolálni, ott már zavarosabb a helyzet. Amikor egy zenei stream "körülbelüli" bitcsomagjainak a bitjeit kell extrapolálni (adott, aprócska időintervallum alatt), ott már helyenként "elszabadul a pokol"."
Még, még Ne hagyd abba, kollégákkal jót mulatunk
-
AMDFan
addikt
Kár vitáznod. Amibe kammerer kapaszkodik, az egy elméleti hibalehetőség ami valóban előfordulhat, olvasd át pár hozzászólással előbb lezso6 levezetését. CRC32 esetén valami hihetetlen pici az esély arra, hogy hibásan fog átmenni az adat (lottóötös nagyságrend). Na erre mi azt mondjuk, hogy 100%-os az átvitel és pont. kammerer meg azt mondja rá, hogy nem 100%-os és pont (biztos lottózik is ). Mivel láthatóan a számokkal nincs nagy barátságban így megpróbálja ezt a minimális esélyt felnagyítani, illetve ilyeneket ír, hogy ha 1000x konvertálsz wav-flac között, akkor torzulni fog az adat meg hasonló nonszenszek (ennek persze nincs köze a tcp/ip-hez csak a sok nonszensz közül ezt kiemelném). Nyilván ha most lescriptelném gyorsan ezt az 1000x-es konverziót akkor ő ettől még nem hinné el, hogy téved, én viszont úgy érezném magam mint egy hülyegyerek akit rávettek arra, hogy közönség előtt bizonyítson egy nagyon nyilvánvaló dolgot.
[ Szerkesztve ]
-
AMDFan
addikt
"egy vidéki faluban, ahol kisírták, hogy az ADSL-t húzzák ki 2,5 km távolságra már korántsem."
De igen. Az a baj, hogy nagyon messziről indulunk, erről egy egész könyv szól, Andrew S. Tanenbaum - Számítógép-hálózatok
Ez egyetemi tantárgy, Tanenbaum írta egyébként a Minix operációs rendszert is.
A számítógép hálózatok több szinten tevődnek össze. Ma már, ha nagyon rossz a kapcsolat, akkor rossz esetben sok lesz a csomagújraküldés, emiatt lassulhat a hálózatod, de még igen rossz minőségű kapcsolat esetén (afrikában pl. nagyon sok helyen rossz minőségű a kapcsolat, de mégis bithelyesen érnek oda az adatok) is teljesen pontos lesz az átvitel köszönhetően annak, hogy a hibajavítás is több rétegben történik. -
AMDFan
addikt
válasz #71562240 #240 üzenetére
Hihetetlen vagy Te komolyan elkezdted elemezgetni a lottóötös esélyét
A lottóötössel kb annyit szerettem volna szimbolizálni, hogy egy átlag user egész életében egyszer sem fog előfordulni az, hogy hibásan tölt le adatot a hibajavítás tökéletlensége miatt, mint ahogyan lottóötöse sem lesz. Ennyire minimális az esély.Bármennyire akarsz kapaszkodni a minimális elméleti esélyedbe, a gyakorlatban nyugodtan ki merem jelenteni, hogy igen, 100% az esélye annak, hogy az adat hibátlanul fog megérkezni.
De az a baj egyébként, hogy te nem csak ezeket a dolgokat nem érted, hanem ilyeneket írsz, hogy két bitazonos wav másképpen fog szólni. Komolyan mondom neked olyan téveszméid vannak a számítógép működésével kapcsolatban, hogy mutogatni kéne...
[ Szerkesztve ]
-
AMDFan
addikt
válasz #71562240 #243 üzenetére
Jó, akkor menjünk bele, mindenféle személyeskedés nélkül. Ha valóban azt mondod, hogy képes vagy tanulni és elfogadni, hogy hibáztál, akkor menjünk bele. Csak kérdéseket szeretnék feltenni, mert lehet, hogy egész végig nem egy dologról beszéltünk.
"Nyilvánvalóan, általad is és mindenki által köztudomásúan érvelésem lényege mindig az, hogy a szokásos "mérőműszerek", pl. Total Comander, Intéző, számítógépes játék"mérőműszerek"... által (jobbára marketingokokból) bitazonosnak mutatott fájlok nem feltétlenül valóban bitazonosak - különféle elvi és tapasztalati megfontolások alapján ugyebár azzal foglalkozunk, hogy nem feltétlenül valóban bitazonosak."
Kezdjük ott, hogy a Total Commander és Intéző nem alkalmas arra, hogy megmondja két fileról, hogy bitazonos-e. Azt tudod megnézni velük, hogy a fileok mérete mekkora. A számítógépes játék mérőműszerek alatt például azt érted, hogy a cikkben is elővett linuxos "diff" program például ide sorolandó, és attól függetlenül, hogy azt mondja két fileról, hogy bitazonos, az a valóságban lehet, hogy mégsem bitazonos?
"én éppenséggel végeztem már jónéhány, közte éppenséggel a nyilvánosság előtt ("ingyért") végrehajtott kísérletet is arra vonatkozólag, hogy például én vakteszten kihallom-e, és mekkora biztonsággal hallom ki valahányszori oda-visszakódolás utáni WAV-FLAC-WAV_FLAC... kódolások eredményeit annak fényében, hogy a "mérőműszer" a végeredményeket bitazonosnak MUTATJA, miközben esetleg másképp szólnak, mint a bitazonosnak MUTATOTT eredeti. A nyilvános kísérlet eredményét ugyebár az illetékes topikban részletesen leírva nyilvánossá is tettem"
Erre én most hirtelen nem emlékszem, volt egy idő amíg nem követtem a Hifis topikot, megtennéd, hogy belinkeled ezeket az eredményeket?
"Na de tényleg, felteszem a költői kérdést, kinek az elborult placebója, kinek az elborult lila ködje, kinek az elborult hozzánemértése, kinek az elborult kóklersége, kinek az elborult fogalmatlansága, ha tíz bitazonosnak MUTATOTT fájl közül x darabot semmi nem tud lejátszani, y darabot fakultatíve játszanak le némely lejátszók, és csak 10-x-y darab fájl van, amelyiket stabilan lejátsszanak a lejátszók?"
Nem emlékszem ilyen tesztre, mivel ellenőrizted hogy bitazonosak-e a fájlok?
szerk: azért kérdezem ezeket, mert amit írsz egy súlyos anomália, ami velem is előfordult egyszer. A netről letöltött dolgok bizonyos százaléka hibás volt, a számítógépem viszont stabilan működött. Ha futtattam CRC ellenőrzést a letöltött adatokra hibát adtak vissza, tehát hibás volt a letöltés. Az oka egy "memtest86" futtatással gyorsan kiderült, a 4x1GB memóriából 1 modul hibás volt.
[ Szerkesztve ]
-
AMDFan
addikt
válasz #71562240 #250 üzenetére
Na elolvastam. Tehát:
"Igen. De ez egy "nagyon erős" igen. Olyan, mintha azt mondanám, hogy "Hát már hogy a patvarba ne?!". És korrekt a megfogalmazásod (kiemelés tőlem): "a valóságban lehet, hogy mégsem"."
Ez szomorú, mert így nem lehet bizonyítani semmit számodra mérésekkel. Most nem térek ki arra, hogy ezt sajnos nem jól gondolod, nyilván tudod, hogy ebben nem fogunk egyetérteni.
"Az adott szövegemben csak visszautaltam a korábban kifejtett esetemre, lásd (#170) kammerer, például a Tool Aenima nagylemezzel. De "sok" ilyen tapasztalatom van - ugyebár másoknak is. És ilyenkor "ellenőrzésileg" megelégszem azzal, hogy például Total Commander "bithelyesnek" MUTATTA a fájlokat, már csak azért is "megelégedtem" ezzel, mert hát hiszen a tökéletes és hibamentes TCP/IP protokollstruktúrán jött át sikeresen, "100%-ban" mindegyik, - hehe, hehe, azzal ellenőriztem, hogy "bitazonosak-e", hogy tudtam, a tökéletes "
Nem jól ellenőrizted valószínűleg. Említetted a rapidshare-t. Ha ilyen oldalakról tölt valaki le fileokat, akkor az ingyenes módon egy lassított sebességet kap általában, ami adott esetben akár meg is szakadhat ha túlterheltek a szervereik vagy az üzemeltetők szándékosan szakítják a kapcsolatokat azért hogy több prémium előfizetőt szerezzenek maguknak, akik megelégelve a szakadozást inkább fizetnek 2 dollárt csak tölthessék már amit akarnak. A letöltés megszakadását többféle módon is kezelhetik a böngészők vagy letöltőprogramok. Akad olyan is, amelyik lekéri a szerverről az ott található file méretét, majd ezt a méretet előre lefoglalja a fájlrendszeren (ilyen pl. a sparse file is), és a letöltés közben írja bele az adatokat. Ha a letöltés megszakad, akkor egy Total commanderrel például azt látod, hogy ámbár ugyanazt töltötted le, és a fájlok ugyanakkorák méretre, viszont az egyiket nem tudja lejátszani a lejátszó a másikat pedig igen. Na ha ilyen esetben megnézed egy "diff"-el vagy hexa editorral, akkor láthatod hogy a két file között különbség van, tehát messze nem bitazonos. Ezt látom lehetségesnek még.
"a tárhelyen (Rapidshare) ilyen-olyan módon kezelt fájlcsomag volt már az "összeomlás határán" a rajta korábban megesett hibák-hibajavítások miatt - utalok vissza, hogy többé-kevésbé sztochasztikusan interpolál(nak) a hibajavítás(i algoritmusok), digitális zeneformátum esetén általában inkább "többé" sztochasztikusan."
Valójában ha egy fájl átvitele közben történik hibajavítás, akkor az nem megközelítőleg lesz azonos az eredetivel, hanem teljesen pontosan, és semmivel sem tudod megkülönböztetni, hogy melyik volt az eredeti. Ez a digitális technika egyik alapelve. Viszont! Ha megmondod, hogy szerinted körülbelül hány wav-flac oda vissza alakítás és hálózaton keresztüli továbbítás szükséges ahhoz, hogy nagyon leromoljon a file minősége, akkor egy scripttel meg tudom neked oldani azt, hogy egy adott wav filet 1000x vagy akár 10000x átnyomjunk a következő megpróbáltatásokon:
1. otthoni gépemen wav-ból flacba alakítom
2. feltöltöm egy németországi szerverre a flac filet ami alatt rengeteg hálózati eszközön megy át, körülbelül 1200km utat megtéve a kábeleken
3. a német szerveren visszaalakítom flacból wavba
4. visszatöltöm az itthoni gépemre a wav-ot, majd újra jön az 1-es pont.Az én állításom az, hogy ezt az iterációt akárhányszor elvégezve egészen pontosan 0! minőségromlása lesz a wav filenak, amellett, hogy természetesen a tízezredik töltögetés, konvertálás, és minden után bitpontosan ugyanaz lesz mint az eredeti wav. és természetesen semmilyen különbséget nem lehet majd hallani köztük.
Én ezt meg is csinálnám, feladva a korábbi álláspontomat, hogy nem akarok nyilvánvalót bizonyítani. Hátha mások is csak akkor hiszik ezt el, ha látják/hallják ezt.
-
AMDFan
addikt
válasz proci985 #255 üzenetére
Jajj erről eszembe jutott, hogy anno az egyetemen volt egy 24 órás programozási verseny, ahol az volt a résztvevők feladata, hogy két számítógép között két monitor és két webkamera segítségével vigyenek át adatokat. Szerintem iszonyatosan érdekes feladat volt, és ugye sokféle implementáció volt kivitelezhető. Pl. sima képernyő villogtatás, fekete/fehér (bináris információ), vagy 16 szin villogtatás (hexa információ), akkor osztott képernyőn még több infó mehetett át
[ Szerkesztve ]
-
-
AMDFan
addikt
Hát nézd. Én a cikkben egy jellemző félreértést szerettem volna tisztázni a puffer kérdéssel.
Mégpedig azt, hogy sokan azt gondolják, hogy az USB Audionál realtime lejátszás van. Tehát ahogy érkezik az adat bitről bitre, a DAC úgy konvertálja, mintha egy analóg jelet játszana le. Főleg az USB Audio kábelek iránti érzéketlenségét akartam ezzel megmutatni, hiszen sokan gondolják úgy, hogy az USB Audio-nál a kábelen sok múlik, hiszen nincs pufferelés a fogadó oldalon. De van! De van!
Bár ahogy látom a kábelfetisisztáknak tök mindegy. Ellenben ha legalább 1 embert sikerült eltántorítani attól, hogy átverjék egy 40-50 ezres UTP vagy USB kábellel, már megérte a cikk, meg a sárdobálás. -
AMDFan
addikt
"Ahogy jönnek egymás után az 1ms-os burst-ök, közöttük lehet lyuk az USB órajelének pontatlansága miatt, ami jitterként nyilvánul meg. Kezelik a problémát, de nem jól."
Ez jogos, viszont ahogy korábban említve volt, ez egy USB1.1-es eszköz, ami 1ms-es bursttel dolgozik, viszont a PCM2902C az már USB 2.0 HiSpeed, ami 0,125ms-es burstöket küld, és annak már 0,25ms buffer is elegendő a fogadó oldalon. Ahhoz képest már az 1ms az tengernyi hely
-
AMDFan
addikt
"USb-nél az adatra rá tud mászni a tápér feszültségzaja."
Most nem tudom, hogy ugyanarról beszélünk-e de én bárkinek bármikor tudom demózni, hogy milyen az amikor egy USB DAC-nál bénán szűrik a zajt. Két DAC-om van, az egyik egy gyári occsó M-audio amit boltból vettem 22e Ft-ért, a másik pedig egy sokak által hozzáértőnek gondolt hazai DIY guru DAC-ja (nem nevezném meg) amit tőle vettem meg az előbb említett chipsettel, jutányos áron 15e FT-ért.
Bus 003 Device 005: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC
Lehet tippelni, hogy melyik DAC az amelyikben bénán van megoldva a tápszűrés és áthozza az egérmozgatás/vinyóműveletek hangját. Ja és ráadásul még sikerült is felcserélnie a jobb és bal csatornát
Ez volt az első és utolsó DIY cuccom amiért pénzt adtam[ Szerkesztve ]
Új hozzászólás Aktív témák
- EDIFIER R1700BTS hangfal pár makulátlan, új állapotban, 2 év hivatalos garanciával, alkalmi áron
- LG OLED55B23LA 2 Év GYÁRI GARANCIA
- Apple iPhone XR 128GB, Kártyafüggetlen, 1 Év Garanciával
- Gamer PC , i7 12700KF , RTX 3080 Ti , 64GB DDR5 , 960GB NVME , 1TB HDD
- Intel PC , i5 8500 , 1660 6GB , 32GB DDR4 , 512GB NVME , 500GB HDD
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest