-
Fototrend
Új hozzászólás Aktív témák
-
#92251648
törölt tag
válasz
orsib78
#1848
üzenetére
Maga a cikk eléggé pongyola és több tárgyi tévedést is tartalmaz, de ugye nem ez volt kérdés.
A FLAC veszteségmentes tömörítés, de mégiscsak tömörítés, amit lejátszásnál ki is kell csomagolni. Nem találkoztam még olyannal, hogy ez eltérést okozott volna hangszínben, de a tömörítetlen állomány lejátszásához képest valóban érzékelhető eltérés, 4 fős vaktesztben magabiztosan ki tudtuk mutatni. Az okát ne kérdezd, nincs elégséges tudásom a magyarázathoz.
Nem hiszem, hogy a tömörítési megoldások más és más lejátszó rendszert igényelnének. De abban van valami, hogy a formátumok megítélésében szerepet játszik a lejátszó lánc is. Pl. a DSD formátum azoknál fog többet adni, akiknek rendszerében a DSD kezelése legalább olyan magas szinten történik, mint a PCM jeleké. Ez messze nem olyan gyakori, mint elsőre gondolnánk, a tisztán natív DSD lejátszás még mindig ritka. Az SA-CD hajnalán némelyik gyártó csaláshoz is folyamodott, a különbség fokozására lerontották a PCM jelutat, hogy a DSD réteg érezhetően jobban szóljon.
A másik idézetnél nem igazán értem, hogy mit akart közölni velünk az író, de itt is vannak fura kijelentések. Rippelés során ha elég időt adunk a folyamatnak és nincs nagyon összekarcolva a lemez, a CD-ről beolvasott adatokban nem lehet eltérés. Ha az író nem rippelésre gondolt, hanem realtime lejátszásra, ott valóban lehet eltérés a környezeti hatások miatt, de nem az adatmennyiségben keresendő. De ez ugyanígy igaz minden más lejátszási megoldásra is.
Az analóg/digitális hitvitához nem szeretnék hozzászólni, ennek már minden aspektusát kitárgyaltuk az elmúlt 40 évben. Műszaki szempontból egyik sem tökéletes. Hogy kinek melyik a szerethetőbb, praktikusabb, olcsóbb, fenntarthatóbb, az meg nem vitatéma.
-
#92251648
törölt tag
válasz
orsib78
#1851
üzenetére
Vettem egy albumot, ami rendelkezésemre állt tömörítetlen verzióban, ebből készítettem közepes tömörítésű FLAC állományt, majd 4 fő jelenlétében random sorrendben lejátszottam néhány részletet FLAC és Wave formátumban. A tesztelők minden esetben meg tudták mondani, mikor melyik formátumot hallják. Ennél tudományosabb módszert nem akartam használni egy baráti összejövetelen. A rendszer elemeire már nem emlékszem, de vélhetően a Luxor PC valamelyik korai verziója volt a főszereplő. Akkoriban gyorsan cserélődtek nálam a cuccok, erről azóta már leszoktam. Egy másik alkalommal minimális tömörítési rátájú FLAC (0) állománnyal megismételtük a tesztet, ott már nem tudtunk magabiztos döntést hozni, a különbség nagyon kicsi és esetleges volt. Azóta én ilyen formátumban tárolom a zenéim nagy részét.
Magyarázattal továbbra sem tudok szolgálni, de azt tudjuk, hogy a végső produkció nem csak azon múlik, milyen hasznos jelek utaznak a rendszeren, a háttér folyamatok is lényegesek, pláne egy számítógépnél.
Minden valamirevaló zenekiadó intézkedett már régi felvételeik archiválásáról. Ahogy írod, a DSD formátumot eredetileg erre a feladatra hozták létre. Amit még nem archiváltak valamilyen digitális formában, azt vélhetően nem is akarják/tudják megmenteni.
[ Szerkesztve ]
-
AMDFan
addikt
válasz
orsib78
#1851
üzenetére
"Kérdés:
Hogy tud máshogy szólni a WAV mint az arról készített FLAC amikor a számítógép bitre pontosan ugyanazt a PCM jelet küldi ki az USB csatlakozóján? Mondom most az egyéb zavaró tényezőktől tekintsünk el, mert azok ugyanúgy hatnak a WAV és a FLAC lejátszásakor is."
Nem szól máshogy. Korrekt vakteszten mindenki elbukik. Ha nem így lenne, tele lenne az internet pozitív vaktesztekkel, és lenne rá magyarázat, hogy miért szól másként a tömörített FLAC. Mint ahogy veszteséges tömörítés esetén tele van az internet korrekt vakteszt eredményekkel és a magyarázat is egyértelmű, hogy miért szól másként. -
#71562240
törölt tag
válasz
orsib78
#1848
üzenetére
Ezt megvitatni hatalmas téma - informatikailag, digitálishanghordozóilag és hallástesztileg. A Prohardver fórumain már sokszor esett ilyesmiről szó (vita, veszekedés), legfőképpen persze a Hi-firől általánosságban topikban, és persze a hatalmas témáról hatalmas kommentfolyamok szoktak létrejönni, de még azok is csak a felszínt súrolják.
A Prohardver ezirányú topikjaiban nagyjából én szoktam képviselni azt, hogy valóban veszteségmentes audiotömörítés (és adatátvitel) legfeljebb laboratóriumi körülmények közötti kegyelmi pillanatokban valósul meg, és nem olyan bonyolult adatfolyamon és nem olyan forszírozott sebességi követelmények között, mint a zenei hanghordozók műveleteinek világa - nem véletlenül én szóltam hozzá az első videódnál is a DAT magnó "bitperfektségéhez". Tehát jellemzően én szoktam mondani és magyarázni, hogy például a FLAC is természetesen veszteséges tömörítés. (De én olyan durva vagyok, hogy a TCP/IP protokoll adatátvitelét is természetszerűleg veszteségesnek szoktam mondani, magyarázni.) A napokban nem fogok erre ráérni, tehát jobbára valószínűleg olyan hozzászólásokkal fogsz találkozni, amelyek arról szólnak, hogy az idézett írás szerzője értelmetlenségeket beszél - ami egyébként nyilván igaz, de nem feltétlenül az általad idézett két részre vonatkozólag.Példa a lehetséges gondolati irányokhoz.
Az x=2y függvény viszonylag veszteségmentes tömörítése azon koordinátapontok felsorolásának, amelyeket a függvény leír. Egy ilyen függvénnyel laboratóriumban jó eséllyel visszanyerjük annak az egyenesnek a koordinátapontjait, és akkor bitperfekt, hurrá. A zenei hanghordozó adatstreamje azonban minden apró időpillanatban folyamatosan változó óriási számú "függvény", tele extrapolálással, amit nagyjából úgy tudnál tényleg veszteségmentesen "tömöríteni", ha a hibaellenőrzéshez és hibajavításhoz szükséges redundancia felbontását legalább egy nagyságrenddel nagyobbra választod, mint amekkora a tömörítendő anyag felbontása - máris ugye nem tömörítés, hanem az ellenkezője. A bitperfektség méréséhez is a mérendő adatfolyamnál legalább egy, de inkább több nagyságrenddel nagyobb felbontású egzakt mérőeszköz egzakt ellenőrző adatfolyama szükségeltetne - nem így szokás ezeken a fórumokon mérni, hanem játékeszközökkel, játékfelbontással. És nem a forrásfájlból készített FLAC-ot kell mérni-hallgatni a forrásfájlhoz (hiszen ott már eleve különbség van a lejátszási körülmények különbözősége miatt), hanem a készített FLAC-ból a forrásfájlba visszabontott "másodforrásfájlt", például eredeti WAV-ot a visszaalakított WAV-hoz.
A például a FLAC tömörítés bitperfekcióját vallók oldalán erős érv tud lenni olyasmi, amire például AMDFan szokott hivatkozni (csinált is ilyesmit például CD-játszó kiolvasóképességét vizsgálva), hogy ha nulltesztet végez úgy, hogy ellenfázisban küldi egymásra a két fájlt, akkor azok tökéletesen kioltják egymást, tehát nulla zaj marad, ergo látható a bitperfekció. Azonban az ilyen elméleti-gyakorlati nulltesztek is a vizsgált adatfolyam felbontásán szoktak elgondolódni vagy megtörténni, ergo nem feltétlenül mérvadóak.A FLAC viszonylag kis veszteségű tömörítés, nehéz kihallani és kimérni a tömörítési veszteségeit-torzításait. Én egy időben gyakoroltam azon, hogy eredeti CD-WAV-ból FLAC-ot visszaalakítva WAV-vá, vak- és nemvaktesztelve hallgatgattam. Egyszeri ilyen oda-visszaalakításnál még relatíve nagyon kicsi a különbség a két fájl között, a gyakorlás korai állapotáról (az andorránál végzett kísérlet) anno a hifitopikba írt kisregényem is azt mutatta, hogy a két fájl közötti hangminőségkülönbségnél jóval nagyobb az a "hangminőségkülönbség", amit az ember önmagának az agyával létrehoz ugyanazon hanghordozó hallgatásakor is, azaz, a placebófaktor esetemben nagyobb volt, mint a fájlok közötti különbség, alkalmasint tízszer oda-vissza alakított fájlok összehasonlításakor is.
Mindazonáltal, ha mondjuk tízszer megcsinálom, hogy a másodfájlból harmadfájlt, negyedfájlt... készítek, akkor mondjuk a tizedik oda-visszaalakítás után már egzaktabbul érezhetőek a különbségek a "játékmérőeszköz" szerint még mindig "bitperfekt" fájlok között. Ha kigyakoroltam magam egy eredeti fájl és a tizedszerre oda-visszakonvertált fájl között, akkor a saját hangrendszeremen 90-100%-os eredményeket tudtam elérni vaktesztben a két elvileg "bitperfekt" fájl megkülönböztetésében. Ergo, ugyanannyi bit volt a két fájlban, de már nem ugyanazok a bitek, ellenben a bitek nemugyanazonságának műszaki méréses kimutatásához minimum egy de inkább több nagyságrenddel nagyobb felbontású egzakt mérőeszköz szükséges. Tehát nagymértékben hatékony dolog a veszteségmentesnek nevezett audiotömörítés, de természetesen nem bitperfekt, legfeljebb laboratórium kegyelmi körülményei között kegyelmi pillanatokban. És ahogy a fapaci által említett kísérletezés is jelzi, számít az is, hogy milyen tömörítési fokú az a FLAC. Nemcsak a fapaci által említett esetben számít, amikor is FLAC volt összehasonlítva az eredeti WAV-jával, hanem akkor is számít, ha a FLAC vissza van alakítva WAV-vá az összehasonlításhoz, amivel azt akarom mondani, hogy a FLAC különböző fokozatai nem csak aszerint különülnek el, hogy mennyi számítási teljesítmény szükséges a használatukhoz, hanem egy kicsit a hangminőségükben is.
Én, ha tehetem, tömörítetlen formátumokban szerzem be az audiofájlokat, és én magamnak biztos nem tömörítek FLAC-ba sem, semmilyen tömörítési fokozaton sem - mert a legkisebb is számít nekem.Na most képzeld el, mekkora kammereriádát tudnék írogatni, ha lenne rá időm. A téma kibontása monografikus terjedelmű - és ismeretigényű. Versus a marketing bitperfektje egy szó.
-.-.-.-.-.-
Az általad idézett másik részletben nincs semmi látnivaló, ott mindössze annyit említett meg a szerző, hogy az analóg lejátszáskor (elvileg) nem erednek "az időegység alatt átvitt korlátozott mennyiségű információ hatásai"-ból problémák. Az analóg lejátszáskor is változik minden alkalommal a kiolvasott adat, de (elvileg) nem "az időegység alatt átvitt korlátozott mennyiségű információ hatásai" miatt. Ennyi.
[ Szerkesztve ]
-
#71562240
törölt tag
válasz
orsib78
#1856
üzenetére
A "bitperfekcionisták" típuspéldája ez a .zip és az írott szöveg betűi példa (lásd még a hittérítők típuspéldái például az óraműről, amely nem tud magától összeállni, teremtő kell hozzá...).
Egy írott szöveg faék egyszerűségű adatállomány, ráadásul nem sérülékeny stream jellegű, mint amilyen a zenei hangfájl tartalma. De, ha elegendően sokszor másolod ki-be azt a "hello"-t, akkor egyre több lesz benne a hibajavított, extrapolált bit, amely hibajavítás az adatállomány a faék egyszerűsége miatt sokáig fog szerencsésen extrapolálni. Ám ha még többször másolod ki-be, akkor egyszer már nem a "hello" lesz olvasható, hanem valami más, miközben az Intéző (vagy a Total Commander) esetleg még mindig "bithelyesnek" fogja mutatni a fájl.
Szokta mondani kammerer.
És persze szokta tesztelni mindannyiunk, "rengetegszer" látván, hogy egyszerű szöveges állományok is el tudnak romlani, miközben még "bithelyesnek" mutatkoznak a kedvenc Total Commanderben. Hát még a zenei stream hogy el tud romlani akkor is, ha konténerben van.De látod, ebből a témából egy Prohardver topikban mindig az van, ami most is elkezdődött. Kulturális szalonban is az van. Audiofil kulturális szalonban is az van. Prohardveren ezt a témát lehetetlen megtárgyalni.
[ Szerkesztve ]
-
válasz
orsib78
#1859
üzenetére
Ez nyilvánvaló. A bitperfekt az bitperfekt. Ha bithelyes, akkor a szöveges állományok vagy zenék nem tudnak "elromlani", bármennyiszer voltak tömörítve. Ha ezer tömörítés és kicsomagolás után is bithelyes, akkor ugyanúgy fog a "hello" megjelenni, mint ahogy a zene is megszólalni.
De szerintem nem ez a lényeg. Szerintem a lényeg az, hogy a lejátszóeszközök a kitömörítés során milyen problémával szembesülnek, és ezek a problémák hogy kerülhetnek át a hangrendszerbe, hogy esetleg kihallhatók legyenek. Én nem tartom lehetetlennek, hogy lehet hallható különbség flac és wav között, de az biztosan nem a bithelyességen múlik, hanem talán a kicsomagolást végző eszköz képességein, például a valós időben történő kicsomagolás sebességén, vagy más paraméterén. Itt lehetne kutakodnivaló a megoldáshoz, nem a bithelyesség kérdéskörében. Talán a lejátszók, flac estén "kicsomagoló"-eszközök képességeit kellene vizsgálni.
[ Szerkesztve ]
-
-
Dißnäëß
veterán
válasz
orsib78
#1871
üzenetére
A HDMI-hez: a digitális átvitel sem garancia semmire, ha nincsenek ellenőrző kódok.
Ez ugyanaz, mint a fájlrendszer: sok ember mai napig abban a tévhitben él, hogy ha van egy fájlja (legyen esetünkben - mivel audio-zunk - zene), kiírta vinyóra és ha nincs fájlrendszer hiba, akkor az X év múlva és 100x átmásolgatva ide-oda ugyanaz a fájl marad.
Hát nem feltétlen. Ellenőrző kódok nélkül cseszhetjük, gyenge rendszeren, vacak RAM-on cseszhetjük.
1. a legtöbb adathordozón nincs gyárilag hibajavítás (tehát valamiféle ellenőrző kód, amivel validálja az eszköz, hogy a beolvasott nullák és egyesek tényleg ugyanazok-e, abban a sorrendben, ahogy kiíráskor voltak. A felület legkisebb hibája, vagy kozmikus sugárzás (ISS-en például erre ügyelni kell), vagy bármi egyéb anomália, rossz táp, szar kábel, na és a mágneses tárolás miatt (is, ha merevlemez például)... akármi egyéb miatt előfrodulhat olyan, hogy kiír az ember 0110100111110010001110100101110101010 -et a HDD-re és ebből visszaolvasáskor az egyik bit átfordul a másikra. Mert demagnetizálódott a hordozó felület azon az egy szektoron, vagy mert bizonyos feszültség értékek határon vannak a fejen, elektronika, tápzaj, akármi miatt, satöbbi, millió ok lehet.
Ami eggyel fentebbi, fájlrendszer rétegben azt jelenti konkrétan, hogy a fájlban egy bájt megváltozik. Az pedig zene, vagy video esetén azt jelenti, hogy ott más lesz a beolvasott tartalom, mint ami kiíráskor volt. Az pedig már nem mondom, mit jelent.
Kritikus rendszerekben, jellemzően szerver környezetben ezért alkalmaznak olyan megoldást, ami hibajavítással látja el magát az adatot, amit el kell vinni A-ból B-be, mondjuk egy HDD-ről egy DAC I2S bemenetére. Ez lenne a NAS vagy Enterprise HDD-k firmware-jébe tett CRC hibajavítás, vagy újabban erre még plusszban a fájlrendszerbe tett blokkszintű checksum-ok, két diszkes redundanciával és erre rájön az ECC memória használata, mert ott szintén (egyéb okok miatt) történnek bit flip-ek, amikor beolvassa a lejátszó program az adatot a memóriába (és bufferel és és és ...) , mire az kimegy a DAC fele, ki garantálja az adat integritását ?
Eszköz és eszköz közötti digitális átvitelben ugyanez megy, és ahol nincs CRC, ott semmi nem garantálja, hogy a küldő oldalon a csőbe tolt 10010100 a fogadó oldalon is 10010100 lesz, tápzaj, jitter, interferenciák, mindenféle ilyesmi után.
Szóval attól még, hogy valami digitális, lehet szar ugyanúgy, ha az implementáció gyenge.
Viszont egy dologban mégis nagyon digitális a digitális átvitel: ha van CRC, az garantálja, hogy egy bizonyos küszöbértéket megugorva az analóg jel (legyen egyszerűség kedvéért "négyszögjel") minősége, ha ebből a hibajavító algoritmus fogadó oldalon elő tudja állítani az eredetileg küldött blokkokat, akkor az onnantól jó.
Tehát mondjuk adó ad egy digitálisan 1001-et, mely feszültségszint-eltérésekben leképződik a kábelre, jön rá raklap zavar, stb, és a túloldalon megjelenik VALAMI.
Amit az ott lévő elektronika első kézben értelmez:
- szar kábel, vevőnél 1011 lesz - adat sérült, senki nem tud róla
- szar kábel, vevőnél 1010 lesz - adat sérült, hibajavító nem tud 2 átfordult bittel már mit kezdeni, vagy tudjuk mert szól, vagy nem, ...
- szar kábel, vevőnél 1011 lesz - adat sérült, hibajavító megoldás digitális térben korrigálja mondjuk CRC alapon a dolgot és előállítja az eredeti 1001-et - adat sérült, tudunk róla és korrigáltuk
- és innentől kezdve mindenféle kábel, ami Tesco gagyi és afelett van, hiába eltérő minőségű, a túloldalt a CRC-nek köszönhetően ugyanazt a helyes 1001-et mutatja végül. Tök irreleváns, hogy 1000Ft-os kábel, vagy 100000 Ft-os csúcskábel.Digitálisnál MINDIG kell nézni, van-e az átvitelben CRC bárhol is a logikai láncban, a digitális jel átvitele során. Mindig. Ha nincs, ott lehetnek eltérések zene esetén a minőségben. Ha van, semmi esélyünk meghallani a HDMI és HDMI kábel közti eltérést, mivel a hibajavítás a szart is bit-perfect szintre hozva kijavítja.
Hacsak olyannal nem jön valaki, hogy a két kábel között a földelés ér/erek minősége más, és ahogy a két eszköz összekötődik egymással, eltérő minőségű föld akármilyen vudut is okoz bármelyik oldalon és vagy az adó ad gyengébb minőségben, vagy a vevő alakít át rosszabbul, bármit is jelentsen ez ..... - nem hiszek az ilyen mesékben (pláne, hogy földet szokták is néha - főleg analógnál, de diginél is működhet - vagy forrás, vagy fogadó oldalon megszakítani, ennek melyikségéről és létjogosultságáról már megoszlanak a vélemények, illetve az omplementációk)......
Nagyon mély víz ez a kábelesdi szerintem, de digitális zenéről beszélve sokmindentől megszabadulunk, ami az analógot még jellemezte. Ami még analógban betudható volt 1-2 vudunak, lásd páratartalom, légköri nyomás, tű súlya, és a macska hol fekszik a szobában, az diginél egy zömében, vagy pláne teljesen hibajavított láncon szépen leomlik, elfelejtjük és kevesebb dolog marad, amibe aztán már bele lehet magyarázni ezt-azt
Még ott is marad elmélkednivaló, de lényegesen kevesebb.Végül: szokták említeni az ABX teszteket. Én ezekben hiszek. A placebóban is nagyon hiszek, de ha azt a placebót úgyis én állítom elő magamnak az agyammal, anélkül, hogy tudnék róla, és egy show-n egy tesco kábelt hasonlítgatok egy atyaúristen kábelhez, persze, hogy jobbnak hallom az atyaúristen kábelt. Show-n soha nem ABX-el senki, hogy kizárja a placebo-t, ők ebből élnek.
Nem mondom, hogy egy Kimber nem szól jobban egy Tesco-s HAMA fekete, kéteres, kosárba bedobott csoffadt kábelnél, de nagyon gyorsan megnő a minőségi ugrás, amit még egyáltalán érzékelünk, egy jobb kábellel, utána viszont érzékelhetetlen a különbség köztük, én ezt vallom. És analógban még csak-csak, de amikor CRC-s átvitel van digitálisan két kütyü között, ott mentehetetlenül megállapíthatatlan a kábel minősége a CRC-zett digi átvitel szempontjából.
Mai technológiával a világ túloldaláról tudok bármivel úgy zenét juttatni a DAC-omba, hogy az bit-perfect onnantól, hogy az analóg jel digitalizálva lett. Ez azért durván jó dolog és jelent valamit.
Azt, hogy mire ide eljön, és amiken eljön, ahogy eljön, kontinenseken, dzsunka iszonyú zajos szervertermeken át és a végén bit-perfect, mutatja annak tényét, hogy CRC digitális átvitel esetén gyakorlatilag a kábel minősége a kritikus küszöbérték felett haláltotálmindegy, és akkor a levegőt még nem is mondtam, amikor mindezt telefonnal, a parton ülve stream-elem egy 4G mobilhálózaton keresztül a Fiio USB-OTG-s DAC-omba mondjuk és a maradék 1 méter fülhallgatóvezetéken, D/A konverzión, opamp-okon többet bukok minőségben instant, mint az azt megelőző 3000 kilométeren, ha mondjuk egy ott host-olt fájlt hallgatok.
Egyébként HDMI esetén alapból nem tudom, van-e CRC (talán nincs). HDMI - HDCP esetén van, mert bár alapvetően jogi oka lett a másolásvédelem implementálásának, mindkét végen egyúttal ellenőrző algoritmusokat is tartalmaz, amik nem engedik a jelet sérülni, vagy ha korrigálható mértékben sérült, azt 100%-osra (!!) helyreállítják fogadó oldalon. Ismét esélytelen meghallani az eltérést ..
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
AMDFan
addikt
válasz
orsib78
#1871
üzenetére
Ez egy szép történet, én is átéltem ilyesmit régebben. Érdemes elgondolkozni azon, hogy most akkor végérvényesen pontot tudtál tenni ennek a végére, elfogadod, hogy ezt te nem értheted és van valami "csoda", valami "titok", amit a világon csak nagyon kevés mérnök tudhat, és fura módon mindegyik az audio iparban dolgozik, VAGY szkeptikusan kezeled ezeket a dolgokat és utánanézel, leteszteled korrekt körülmények között. Az Audioquestnek volt már scam botránya egy youtubeon közzétett HDMI összehasonlító videó miatt, amelyben szimplán ráraktak egy EQ-t a felvételre, és ezzel demózták a különböző HDMI kábelek hangját. Audioquest, Entreq = SCAM.
-
-
Ribi
nagyúr
válasz
orsib78
#1888
üzenetére
Igen, meg a másolásvédelmes szabványok, meg tömörítési módok a másolás védelem miatt, elég sok dolog történik HDMI kábel 2 végén. Mondom ezt csak így hasraütésre mondom, de szerintem könnyen meg lehet oldani, hogy 2 ugyan olyan kábel mókolás után ne ugyan úgy kösse össze a 2 eszközt. Egyik esetben minden szép és jó, másikban meg plusz tömörít, mert "nem biztonságos" a másik oldal.
-
#92251648
törölt tag
válasz
orsib78
#1861
üzenetére
"Én is ezen morfondíroztam, hogy talán valami sokkal elemibb szinten van különbség, ami nem az adattartalomra vonatkozik."
Javaslom, maradj ezen a logikai úton! A számítástechnikusok azonnal a bitek tartalmára koncentrálnak, mert ők ehhez értenek. Ám a valós idejű lejátszás és adattovábbítás nem azonos sem a file másolással, sem a tömörítéssel, ezeknél sokkal bonyolultabb és merevebb folyamat. Ezernyi példát lehetne hozni arra, a bit-perfect átvitel miért nem garancia semmire, pl. egyes digitális jelforrások produkciója miért tér el egymástól, de már szörnyen unalmas ez a vitatéma. Minden érv elhangzott az elmúlt években, az álláspontok mégsem változtak, de néhányan sokadszorra is meg akarják erőszakolni egymást.
-
Dißnäëß
veterán
válasz
orsib78
#1898
üzenetére
Gyenge próba. Sajnos még sehol nem tart ZFS-hez képest, miközben a ZOL (Zfs On Linux) mióta külön-fork-olódott a nagy FreeBSD-s ZFS-ről, elkezdett nagyobb iramban is továbbfejlődni, nemsokára kész például a raidz (raid5-6-7 ekvivalensek) egyes szintjein annak kezelése, hogy mondjuk egy 3-lemezes raidz1-et (raid5-öt) még egy diszkkel kiegészítsünk és bővítsünk, szóval a komplexebb, paritás alapú raid szintek közötti migráció. Ez azért elég állat. Btrfs-eztem pár hónapig, elég hardcore módon, volt két összefosásom fájlrendszer szinten, ok nélkül, úgyhogy letettem róla. Stabilnak mondott a standalone és raid1 implementációja, de minden más még experimental, a Microsoft is fejleszti az ReFS-t elég erősen, még az is jó lehet nem-Linux fronton, de az sem az a hűde... (bár azt Windows Server 2012-re találták ki elvileg, sok dráma ott sem várható).
De btrfs-t nem lehet egyelőre egy lapon említeni ZFS-el. ZFS-re az életem rá merném bízni, kis túlzással, óriási múltja van, nagyon stabil cucc és nagyon kreatívan kezeli a checksum-okat is.
Linuxon pl. dm-integrity-vel meg lehet oldani, hogy egy meglévő akármilyen fájlrendszer (ext2-3-4, xfs, egyéb) integritás-ellenőrző checksum-okkal legyen ellátva, de egyrészt nem mindegy, hova tesszük ezeket az ellenőrzőket (csak a zfs teszi az adattól külön máshova, dm-integrity például az adatblokkok mellé teszi annak checksum-ját), és az sem mindegy, hogy online képes-e az öngyógyulásra, miközben mondjuk beolvasol róla.
Gondolj bele, egy minimum két diszkes NAS, amin úgy van adatod, hogy olvasáskor ha esetleg hiba lenne, automatikusan öngyógyul, illetve egy heti vagy kétheti vagy havi önellenőrzés végigmegy a teljes adatmennyiségen, amit tárolsz rajta. Így gyakorlatilag amíg forog HDD-d vagy megy SSD-d a gépben, addig konzisztens minden adatod. Ezzel így mától fogva az idők végezetéig el lehet menni, ahogy fejlődik az IT, másolva az adatokat 100% konzisztensen rendszerről rendszerre, médiumról médiumra. Elég jó. Lehet 100 év múlva az unokám azokat a fájlokat (vagy ki tudja miket, ha változik a logikai rend) fogja hallgatni majd a hiperszuper agyi interfészelt izéjén keresztül, amiket én ma megveszek neki offline (korong és rip-elem), vagy online. Ez tök jó
De hogy már most létezik ez a technológia, hogy konkrétan még engem is szolgáljon 80 éves koromban, ha akkor még emberi életem lehet, szintén tök jó A btrfs-nek még kell fejlődnie, amúgy ígéretes alternatívája volt a ZFS-nek, míg a ZFS nem jelent meg Linuxra, de most, hogy már egy ideje ez megtörtént, azt látom, hogy rengetegen cuppantak rá rendesen, mert nagyon stabil, hétpróbás kódbázisa van BSD berkekből.. szerintem ha el is tolják a btfrs-t addig, hogy nagyvállalati környezetben is merje bárki használni, még évek.
A zenekollekciómat mindenesetre nem bíznám rá. De mondom, ment jópár hónapig btrfs tükrön motyóm, de egyszercsak aucs, jött pár error a semmiből. Szó szerint.
Visszatérve a szuper NAS-ra, vagy onnan játszol le közvetlenül egy külső DAC-ra, vagy Etherneten/Wifin keresztül (amiken ugyen alapból van 32-bites CRC
) küldöd el egy spéci lejátszóhoz, ahol aztán helyben ki lehet élni a vudu hajlamokat, én például egy Raspberry Pi 4-ben találtam meg a nirvanát, mint lejátszóban, persze kellően felokosítva (ezt építgetem mostanság).Btrfs: jó, de óvatosan. Tavaly a RedHat bejelentette, hogy elavultnak tekinti a btrfs-t (ez nagyon nagy szó a szakmában), a SUSE pedig azt, hogy már csak raid10-ekvivalens konfigurációban támogatja azt. Sok a btrfs-ben a bug és nem, vagy lassan oldódnak meg a nyűgjei.
A COW típusú fájlrendszerek közül a ZFS-nek már nem a Btrfs az ellenfele, hanem - sajnos - senki. A verseny mindig jó, sokkal jobb, mintha monolitok nőnének ki a földből, ami köré épült ökoszisztémát és nagy várat egyszercsak vagy földbedöngöli valami licensz kérdés, vagy megveszik és szétcseszik, vagy egyéb szar történik vele. Van egy ígéretes versenyző OpenZFS mellé, a bcachefs, előbb-utóbb ránézek erre is, de szerintem jó ideig én zfs-en leszek, mert egyszerűen "fasza", nincs jobb szó rá. Ééééés aktívan dolgoznak most is a Windows-os portján, az külön pirospont... ma ami még egy dual boot-os workstation nálam (tartom a Windows-t Photoshop és 1-2 alapjáték miatt), holnap már olyan gép, amin töknyolc, mit választok indításkor, de ha néha Windows-ba is bemegyek, ott látom ugyanúgy a teljes NAS-t, zfs támogatásnak köszönhetően. Marha jó lesz
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
szazbolha
addikt
válasz
orsib78
#1908
üzenetére
A monolitikus adattárolásnál mindig jobb az elosztott. Térben és tárolás megvalósításában is. Főleg ha elhisszük hogy a digitális eszközeink nem rendelkeznek hibajavító mechanizmusokkal.
Egyébként ha ez igaz lenne, akkor a fájlok másolásával mint egy vírus úgy terjednének a hibás adatrészek, sőt nem csak terjednének, hanem folyamatosan gyarapodnának.
Én még nem találkoztam ezzel a jelenséggel. -
Dißnäëß
veterán
válasz
orsib78
#1908
üzenetére
Jó az irány, tetszik a motyód
Ez így korrekt.Adat integritás. Háttértáron a ZFS és hasonló állatok a megoldás (vagy fizikai raid kártyák nyújtják ezt, de azokkal néha nyűg van hiba esetén + eléggé zárt cuccok, soha nem vállalnám be), memóriában pedig az ECC ugye - és pipa.
Ráadásul a ZFS-nek kell a memória, nem kicsit, nagyon. Egy 4TB-os RAID10-es tömbnek neki sem szabad állni 16Gbyte RAM alatt. Igaz, de nem betonfal limitáció, amíg nem használsz deduplikációt. A 4TB-os raid10 tömb elfut 4-8G RAM körül is, jó teljesítménnyel
, míg a dedup nincs bekapcsolva (default off amúgy és senki nem ajánlja, én sem, bár teszt gépen jól működött, csak zene, film, egyebeket tároló gépen nagyon pici a valószínűsége, hogy két egyforma fájl létezzen és azt 1 fizikaiban tárolja, erre meg külön egy nyilvántartó táblát tartson RAM-ban). Szóval dedup nélkül nepara a ZFS-től, a 8G ECC-ddel simán Sokkal fontosabb zfs sebességnél a fícsörök jó használata, 4K AF meghajtók kezelése és 1-2 extra paraméter, melyekkel optimalizálni lehet a pool-okat (főleg az írás-olvasás sebességét, ez nem mindig úgy triviális, mint klasszik raid-nél). De alapból se rossz a beállítás amúgy.
Hálózat: tök8, kábel vagy wifi. Adatot viszünk át, nem jelet... az adat a hasznos terhe annak a szállítmánynak, amivel a DAC-odat eteted, az előtte lévő lejátszó program segítségével a CPU-val, RAM-al , bufferekkel... Szóval töknyolc, hogy a szenet mikor mi szállítja, egyszer vasút, egyszer hajó, egyszer teherautó és az is mindegy, mikor melyiken történik egy kis hiba, amíg a Te szened ugyanaz a szén, mint amit a feladó összepakolt Neked.
Érdekes setup-od van. Én most Pi4-ezek, még nézem a kuckót hozzá Aliexpress-en, nem tudom, mekkora lesz a toroiddal, Arduino-val meg minden bigyóval együtt (helyileg hogy férek el). A Pi4-et meghűtöm bordákkal, így vettem hozzá egy 20cm-es régi IDE kábelhez hasonló szalagkábelt, amivel a GPIO portjait elviszem tőle oldalra kicsit, így a házon belül is tudom árnyékolni a kicsit zajos Pi-t, meg bordázni is tudom passzív módra úgy, hogy közben a GPIO-ra a kábel segítségével pakolhatok kütyüket. A szalagkábel túlvégére, ami a GPIO portokat reprezentálja, kerül egy I2S reclocker modul, arra pedig egy HDMI transmitter, ami HDMI LVDS formában adja ki a jelet egy túloldali, majdani külső DAC-nak (max PCM 768kHz/DSD1024 natív).
A kütyün egy SD kari rendszernek, semmi más. Wifi, Volumio, hálózaton keresztül látja a NAS-omon lévő fájlokat és kész is, más dolga nem lesz. ON/OFF az Arduino-n keresztül, ami majd távszabályzóról kapja a jelet és húzogatja a reléket
+ szól a többi Arduino-nak a rendszerben, ami a többi eszközömet vezérli, így a teljes lánc több alkatrésze egyetlen egy távszabályzó gombnyomásra éled fel és alszik el, ahogy akarom.Apámnak karácsonyra raktam össze ezt, ő egy lépéssel előrébb van, a HDMI kütyüt most kapja meg maholnap
Mondtam neki, kezdje tömni a malacperselyt 2020 karácsonyra, kell az a DAC DAC-ot pedig majd választok innen, mármint mint oldalról.. érdemes a linken lévő függőleges oszlopos képet jobban megnézni (nagyítható), milyen márkák mérve hova esnek. Olykor csak pislogok, hogy mivan.
Aztán úgyis indul majd a cserebere, ez a kütyüzés már csak ilyen
Beszippant.Egy szó mint száz, szerintem nyugodtan állj át ZFS-re, akkor kapsz integritást is az adatokra, addig csak tárolod, de se a proci, se a fájlrendszer, se semmi nem ellenőrzi, azt olvassa-e fel, amit korábban kiírtál.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
![;]](http://cdn.rios.hu/dl/s/v1.gif)
) küldöd el egy spéci lejátszóhoz, ahol aztán helyben ki lehet élni a vudu hajlamokat, én például egy Raspberry Pi 4-ben találtam meg a nirvanát, mint lejátszóban, persze kellően felokosítva (ezt építgetem mostanság).
, míg a dedup nincs bekapcsolva (default off amúgy és senki nem ajánlja, én sem, bár teszt gépen jól működött, csak zene, film, egyebeket tároló gépen nagyon pici a valószínűsége, hogy két egyforma fájl létezzen és azt 1 fizikaiban tárolja, erre meg külön egy nyilvántartó táblát tartson RAM-ban). Szóval dedup nélkül nepara a ZFS-től, a 8G ECC-ddel simán Új hozzászólás Aktív témák
- Napelem
- Projektor topic
- iPhone topik
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Az USA nem akarja visszafogni Kína növekedését
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Skoda, VW, Audi, Seat topik
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Gumi és felni topik
- Android alkalmazások - szoftver kibeszélő topik
- További aktív témák...