Általában a hifiről

[Sosztakovics]

Az antihifizmus megjelenésének egyik kiváltó oka, hogy (nagyon)sokszor egy, a hifista által szubjektíve "tapasztalt" jelenséget műszakilag akarnak megmagyarázni - rosszul - a hifisták. Műszaki tényeket nem lehet hozzáigazítani a szubjektumhoz, mert úgyis leválik róla. :)
2 lehetőség adódik. Csak szubjektíve kell döntéseket hozni hifivel kapcsolatban, és a kommunikációban is csak az ahhoz tartozó kifejezéseket használni, vagy komolyabban kell nekifeküdni a műszaki megoldásoknak, semmiképpen nem olyan elméleteket gyártani, amik tényszerűen és könnyedén cáfolhatóak.

Szerinted a statement kategóriájú termékeket kiknek szánják a fejlesztők? A botfülű, kottát olvasni nem tudó iparmágnásoknak? Vagy nekem, a ruppótlan zenebolondnak, aki egyszer hátha megengedhet magának egy DarTZeel/Rockport párost? Mit gondolsz, kiknél szeretnék látni a mérnökök ezeket a termékeket? Lehet, hogy szívük szerint szelektálnának közöttünk? Pl. te kapsz, mert nálad jó helye lesz, kiérdemelted, te meg kizárt, akkor inkább elégetem? Ezt csak azért kérdem, mert menetrendszerűen megy itt a fikagyár, és meglehet, hogy ők meg rendesen hánynak tőlünk, a bejegyzéseinktől, a tartalmi és formai igénytelenségeinktől, és csupán szükséges rosszként tekintenek legtöbbünkre, akiknek a pénze sajna kell ahhoz, hogy ők valami grandiózust létrehozhassanak, és legszívesebben csak pár ember számára alkotnának, olyanoknak, akik igazán tudják értékelni és a helyén kezelni az erőfeszítéseiket.

[ZolaBA]

BÁRMELY streamszolgáltató egymással AZONOS, értsd AZONOS streamtermékeiről

Nem lennék meglepődve ha itt is lenne egy kis félreértelmezés.
Nincs egy konkrét poros szerver egy folyosó végén Pink Floyd matricával...
Az amazon vagy bármely más tárhely szolgáltató, google, stb. X szolgáltatónak (pl. Tidal, Spotify,stb.) Y gigabyte tárhelyet ad és nem a Pink Floyd zenét. Ha van mondjuk A/B/C zene szolgáltató akkor azoknak van külön AX/BX/CX tárhely területük, ahol AX1/AX2/AX3, BX1/BX2/BX3, stb. formátumban maguknak tárolják a zenét. Miközben az AX/BX/CX tárhelyek nemhogy azonos szerverek lennének, hanem több száz szerveren, több telephelyen, több kontinensen, és több példányban, kellő redundanciával és terhelés elosztással.... Szóval a kedvenc Pink Floyd albumom legalább 50 példányban meg van...

Miközben ez ettől még mindig lehet azonos ugyanis hiába van AX1-ből 6 példány és BX1-ből is 6 példány - ha a kiadó ugyanazt töltötte fel A-nak, mint B-nek.

[Aszpirin]

Ezért is teljesen felesleges itt UDP/TCP szinten okoskodni, mert a tidal/sporify/YT/netflix adatfeldolgozási megoldásainak sajátosságai ennél ezerszer összetettebbek.

Csak két gondolat ehhez, bár nem teljesen az audio témához tartozik, de ha már "nagyüzemi" streaming szolgáltatásra került a szó:

1. Volt szerencsém még 2016-ban bejutni és személyesen résztvenni az AWS re:Invent-en Las Vegasban a Chaos Monkey egyik atyjának egy kisebb körű (kb 30-40 fős hallgatóságú) előadásán, sőt, a végén egy-két mondatot is tudtam váltani vele. A Chaos Monkey a Netflix (egyik) alapvető és (első ránézésre meghökkentően) "eszement" teszteszköze, amely teljesen élesben, random módon (kaotikusan) kilövi a Netflix néhány produktív mikroszervizét, akár egy-egy szerviz minden példányával. A cél, hogy élesben figyeljék meg a rendszer szolgáltatásainak stabilitását. A Chaos Monkey "szabotázsakciói" nem rogyaszthatják meg a Netflix egyetlen szolgáltatását sem. Az egész előadás erről szólt (a miértekben és hogyanokban van egy halom érdekes részlet), és egy adott pillanatban a srác felvillantotta a Netflix mikroszerviz-architektúráját, hogy érthetővé váljon, miért csak élesben tudják megcsinálni ezt a folyamatos rendelkezésreállási tesztet: az mikroszerviz-architektúra akkora, olyan komplexitású, és olyan kaotikusan terhelt, hogy anyagi és technikai képtelenség reprodukálni tesztkörnyezetben mind az architektúrát, mind pedig annak valósághű terhelését, hogy a rendelkezésre állást tesztelni lehessen. A Chaos Monkey egy kényszerszülte okos megoldás erre a problémára, és folyamatos üzemben van. Vagyis, amíg netflixezünk, folyamatosan "szabotálja" a működést, teszt célokkal. És ebből mi semmit nem veszünk észre. Azóta vannak már "felsőbb szintű" változatai (Gorilla, Kong), amelyek pl. nem mikroszervizeket lőnek le, hanem mondjuk egy-egy teljes AWS régiót (a rendszernek észrevétlenül át kell állnia egy másik régióra, és a szolgáltatás nem akadozhat). Mindeszt szintén élesben. Ezt már több mint 10 éve művelik, és ha sikerül gondot okozni az éles szolgáltatásban a segítségével, akkor azt azonnal hibaként kezelik. Azt hiszem, ez mndent elmond a Netflixről, a fejlesztői hozzáállásáról, adattárolási, -feldolgozási. -továbbítási és egyéb funkcionális megoldásairól. A Youtube-ot nem volt szerencsém így "belülről" látni, de tekintettel a tapasztalt minőségére és a teljesen nyilvánvaló méretére - szerintem 100%, hogy hasonló ezen a téren.

2. A valóban realtime kommunikációs platformoknál tényleg van kép- és hangeldobás is rendesen, ezzel személyes napi tapasztalatom van, és szerintem nem én vagyok az egyedüli, aki tapasztalt ilyent mondjuk egy sokszereplős Teams-meetinngben. Nálam rendszeres akkor is, ha lekapcsolom a céges VPN-t, és így ki elméletileg tudom használni a 2Gbps-es itthoni telekomos internet teljes sávszélességét (ami mellesleg a gyakorlatban lehetetlen egy videokonferenciával - de nem az ethernet-portok gigabites korlátja miatt mert nálam mindkét gép 2.5GBASE-T switcheken és thunderbolt-átalakítókon keresztül "emészti" a hálózati sávszélességet. Ez persze lehet a Teams szarsága is, de a korábbi rendszereink (Circuit, Livemeeting) is művelték bőszen, szóval hajlamos vagyok a realtime kommunikáció általános problémájának tekinteni - bár ebben tévedhetek.

[asebestyen]

Az antihifizmus megjelenésének egyik kiváltó oka, hogy (nagyon)sokszor egy, a hifista által szubjektíve "tapasztalt" jelenséget műszakilag akarnak megmagyarázni - rosszul - a hifisták. Műszaki tényeket nem lehet hozzáigazítani a szubjektumhoz, mert úgyis leválik róla. :)
2 lehetőség adódik. Csak szubjektíve kell döntéseket hozni hifivel kapcsolatban, és a kommunikációban is csak az ahhoz tartozó kifejezéseket használni, vagy komolyabban kell nekifeküdni a műszaki megoldásoknak, semmiképpen nem olyan elméleteket gyártani, amik tényszerűen és könnyedén cáfolhatóak.

[zenta]

Néha érdeklődéssel, aztán egy idő után elképedve olvasom ezt a vitát. Vagy más topikokban is folyó, újra és újra fellángoló platformharcot. A műszaki részekhez nem értek (bár érdekelnek), de se papírom, se megfelelő tudásom nincs hozzá. A zenehallgatás viszont életem szerves része. Elnézést, hogy magammal példálózok. Aláírásomban látható rendszeremben - kérem tekintsetek el attól, hogy ki hogyan ítéli meg (én szeretem) - hallgatok analóg forrást (LP), digitálist (CD, ill. roon-on keresztül Tidal-t, Qobuz-t és NAS-on levő zenéket. Hogy milyen arányban az most nem érdekes, annál is inkább, mert azonnal valamilyen platform elkötelezettjének kiálthat ki, aki akar. A lényeg, hogy mindegyiken élvezettel hallgatok zenét. A dolgozószobámban van egy "kis" rendszer ott csak roon végponton keresztül hallgatok zenét. Itt a magyar DAC után Kingrex T-amp trió hajtja meg a részben saját készítésű szélessávú (jaj!) hangsugárzókat. Gyakran ülök ide is be munkán kívül, csak zenét hallgatni. És ha zavarnék valakit a zenehallgatással (ez azért ritkábban fordul elő), akkor felveszem a fülest.
Igen, mindegyik rendszer másképp tolmácsolja a zenét, másért jó. És ezt élvezem. Miért írom mindezt le? Mert ha többféle dolgot hallgatsz otthon vagy barátoknál, az szerintem jó tesz a fülnek, jót tesz a becsípődések ellen, ahogy a koncertre járás is.
Jó volna arról beszélgetni itt a fórumon, hogy valós tapasztalat alapján egy adott rendszer pl. miben jó, miért teszik, esetleg miért nem. Ahelyett hogy bármilyen érveléssel azt bizonygassuk, hogy a másik - sosem hallott és sokszor ismeretlenségbe burkolódzó - rendszere csak azért, mert analóg vagy digitális, csöves vagy tranzisztoros (és így tovább és így továbbb...) a legjobb vagy épp a legrosszabb a világon. Lehet, hogy naív vagyok?

[kammerer]

Aki nem tudná esetleg, illetve minden "hozzáértő" illetékesnek:
- a Spotify OGG Vorbis tömörítést használ, ami veszteséges. Az igényelt sávszélesség előfizetéstől függően 160 vagy 320 Kbps (háromszázhúsz kilobit per másodperc), (tehát ha TCP alapon lenne, tuti rombadöntené a z egész internet hálózatot)
- a Tidal FLAC tömörítést használ, ami veszteségmentes. A streamelt FLAC legmagasabb igényelt sávszélessége (24bit/192 esetén) 9,126 Mbps (kilenc egész 126 század megabit per másodperc), de a Tidal most tér át a HiRes FLAC-ra... A CD-minőségű streamelt zene igényelt sávszélessége 1,411 Mbps.

fapaci írta:
Jó, akkor a kedvenc ILLETÉKESEIDNEK (monogramja KF?) üzenem, hogy a Spotify - talán az egyetlen zenei streaming szolgáltatóként - nem a hozzá feltöltött állományokat közvetíti tovább a felhasználók felé, hanem saját hatáskörükben átkódolják azokat.

Audio file formats for Spotify

Azt már csak halkan írom, hogy - ellentétben a legtöbb szolgáltatóval - a Spotify nem (NEM!) az Amazon AWS szerverparkját használja.

Hibáztam, félreértés keletkezett.

Nem Spotify veszteséges és nem Tidal veszteségmentes termékről volt szó, és nem Spotify-ról és nem Tidal-ről, hanem BÁRMELY streamszolgáltató egymással AZONOS, értsd AZONOS streamtermékeiről - amelyeknek vannak ilyenjeik. A Spotify és a Tidal csak amiatt került elő éppen így véletlenül párban, mert a korábbi témára vonatkozó összegzésében juliush véletlenül éppen ezeket említette az elterjedtek közül, példaként az egyéb, korábbi témára, lásd "Az olyan elterjedt streaming szolgáltatók esetén, mint a Spotify, vagy a Tidal, a nagy valószínűséggel Amazonnál futó szerverek...", ami juliush szövege, én pedig a szövegét idézve válaszoltam neki, amely szöveg egyébként más témára vonatkozott, függetlenül attól, hogy éppen e két szolgáltatónak vagy bármelyik zenestreamszolgáltatónak milyen streamtermékeik vannak.

Sajnos a juliush-hoz intézett válaszomban, amikor a korábbi témát anekdotaként kiterjesztettem a streamszolgáltatók azonos streamtermékeire, óvatlanul továbbhasználtam juliush idézett példakészletét, nem gondolván arra, hogy éppen e két szolgáltatónak létezik-e AZONOS, azaz AZONOS streamterméke, éppen e két szolgáltató közül érvényes-e mindkettőre, hogy milyen szerverről szolgáltatnak. A hibáért minden érintettől elnézést kérek. Úgy az olvasóktól, mint a hibám miatt a Spotify szintjére degradálódott Tidal-től, és mindenekelőtt az én hibám miatt a fapaci által említett KF kabátlopási ügybe keveredéséért. Ostoba hiba. Hamu megy a fejemre.

[Sosztakovics]

Aki nem tudná esetleg, illetve minden "hozzáértő" illetékesnek:
- a Spotify OGG Vorbis tömörítést használ, ami veszteséges. Az igényelt sávszélesség előfizetéstől függően 160 vagy 320 Kbps (háromszázhúsz kilobit per másodperc), (tehát ha TCP alapon lenne, tuti rombadöntené a z egész internet hálózatot)
- a Tidal FLAC tömörítést használ, ami veszteségmentes. A streamelt FLAC legmagasabb igényelt sávszélessége (24bit/192 esetén) 9,126 Mbps (kilenc egész 126 század megabit per másodperc), de a Tidal most tér át a HiRes FLAC-ra... A CD-minőségű streamelt zene igényelt sávszélessége 1,411 Mbps.

Komolyzenei felvételeknél ehhez még hozzájön az is, hogy olykor az előadás maga is veszteséges. A drága művészek lespórolják az ismétléseket, ütemeket hagynak ki, díszítéseket felejtenek el...Ők is tömörítenek, csak másként.

[Luxor Audio]

És ha (HA!!!) igaza van az általam hivatkozott illetékeseknek, akkor persze neked (se) abban sincs igazad, hogy az AZONOS TERMÉKEIKBEN más tömörítési eljárást alkalmaznak, mert akkor ők nem alkalmaznak semmilyen tömörítési eljárást, csak az informatikai háttérről gondoskodnak avégett, hogy az Amazon szerverről A KIADÓ ÁLTAL odadobott fájl elmenjen az azt kérő fogyasztó készüléke felé - én nem tudom, hogy így van-e, velem szemben ebben nem tudsz ellentmondani, mert nem én mondtam, hanem illetékes hozzáértőket idéztem,

Jó, akkor a kedvenc ILLETÉKESEIDNEK (monogramja KF?) üzenem, hogy a Spotify - talán az egyetlen zenei streaming szolgáltatóként - nem a hozzá feltöltött állományokat közvetíti tovább a felhasználók felé, hanem saját hatáskörükben átkódolják azokat.

Audio file formats for Spotify

Azt már csak halkan írom, hogy - ellentétben a legtöbb szolgáltatóval - a Spotify nem (NEM!) az Amazon AWS szerverparkját használja.

[gomolalaci]

Van valami különösebb oka, hogy ékezetek nélkül írsz?

Kikapcs
Igen! Mert ez a divat, meg a félszem.... Így is lehet majmolni a Nyugatot....
Bekapcs

Amúgy Lackó, te miért hagyod el a szavak felét, mikor az ékezetekért küzdesz? (kapcs...)

A kérdés nekem szólt? Nem tudom mire gondolsz, idézd fel bennem, de ha nekem szólt a ,,Lackó" akkor neked semmiképpen nem vagyok az....

[Aszpirin]

Aki nem tudná esetleg, illetve minden "hozzáértő" illetékesnek:
- a Spotify OGG Vorbis tömörítést használ, ami veszteséges. Az igényelt sávszélesség előfizetéstől függően 160 vagy 320 Kbps (háromszázhúsz kilobit per másodperc), (tehát ha TCP alapon lenne, tuti rombadöntené a z egész internet hálózatot)
- a Tidal FLAC tömörítést használ, ami veszteségmentes. A streamelt FLAC legmagasabb igényelt sávszélessége (24bit/192 esetén) 9,126 Mbps (kilenc egész 126 ezred megabit per másodperc), de a Tidal most tér át a HiRes FLAC-ra... A CD-minőségű streamelt zene igényelt sávszélessége 1,411 Mbps.

[diagnet]

Aki autózott már gyenge térerőben és közben próbált stream forrásból zenét hallgatni (velem többször is előfordult mostanában az Alföldön), az megtapasztalhatta, hogy ha nem érkezik kellő adat, a lejátszás minősége nem romlik, hanem el sem indul. A realtime stream / élő közvetítés másként viselkedik, az nem áll meg, tőlünk függetlenül zajlik, maximum kockásodik, szaggat a kép, kimarad a hang, stb., ha gyenge a kapcsolat, de tolja rendületlenül.

Az, hogy beszaggat, kockásodik, vagy teljesen megáll a kép/hang nem attól függ, hogy a "közvetítés élő" vagy már előre adathordozóra rögzítve lett. Kizárólag protokoll és szoftver/HW kódolás/dekódolás, latency, puffer méret határozza meg.
Bárki tudsz élő közvetítést indítani a telefonjáról úgy, hogy az valóban élőben megy, de úgy is, hogy előre rögzített tartalmat indít egy meghatározott idősávban. A YT vagy a twitch nem fog már kockásodni. A legtöbb helyen adaptiv/multi bitrate megoldásokat használnak. Nincs sérült képkocka, se "hangjel", adatkapcsolati vagy sávszél hiba esetén néhány eldobott frame után alacsonyabb bitrátán próbálkozik. De minden esetben ugyanaz a bitperfekt adat érkezik meg a klienshez mint amit a YT vagy OBS renderer előállított.
A kockásodás az ősrégi RTP RTSP protokolloknál és mpeg kódolásoknál volt jellemző, az olcsó webcamerák a mai napig ezt használják. De azok az idők 20+ éve elmúltak. Ezért is teljesen felesleges itt UDP/TCP szinten okoskodni, mert a tidal/sporify/YT/netflix adatfeldolgozási megoldásainak sajátosságai ennél ezerszer összetettebbek.
Azok tudják követni akik középiskolás-egyetemista koruk óta megszállotjai voltak a témakörnek és azóta minden idejüket ebben a közegben töltötték. 20 éve még voltak olyan csatornák, ahol kvázi gyerekként követni lehetett a munkásságukat és naprakész információhoz lehetett jutni, miközben ők a gattyán féle hálózatnak meg mindenféle darkwebes warez "streaming" platformoknak ácsolták a hátterét. Civilként már akkor is átfoghatatlan volt az a tudásanyag amit néhány év alatt magukba szívtak. De ennek ára volt. Szociális élet 0. Az egyetemisták egy része antidepresszánson élt, hogy egyáltalán el tudja viselni ha emberek közé kell menni. Volt olyan idősebb programozó aki évente 1x állt fel a géptől, akkor is a redundancia és a túlélés jegyében hetekig készült egy hétvégi túrára a börzsönybe. És ez még csak az első generációs magyar vonal. A globális streaming platformok létrehozói még ennél is durvább lények lehetnek. Innen senki sem cserélne velük, hogy elmondhassa ért hozzá.

[ZolaBA]

Amúgy. Van olyan parancs ami listázza milyen hálózati kapcsolatok vannak, milyen protokollon
De persze én nem vagyok informatikus, pláne nincs diplomám bródkásztingból.

[kammerer]

"Vadász, vadász, te...jársz ide"

Nem járok ide, de valóban megszopattattam - (el)szenvedő szerkezet.

[kammerer]

...és ezért is kicsit nehéz magyarázni a köztük, például a Tidal és a Spotify azonos streamtermékei között levő jelentős általános hangminőségkülönbségről szóló általános tapasztalásokat vagy tapasztalni véléseket.

Fennen hangoztatott szakmai előmeneteledre némi árnyékot vet a tény, hogy a két említett szolgáltató erősen más tömörítési eljárást és adatformátumot alkalmaz, tehát pont ezeknél logikátlan vitatni a hallható különbségeket. No de az én lelkesedésem eddig tartott.

Beszéljünk az én lelkesedésem kitartásáról is.
A kommunikációs módszer megint tipikus - tudnék néhány internetközhely "érvelési" hibát idevonatkoztatni. Például a más szövegét kiragadni nem csak a kontextusból, de egyáltalán a szöveg egészéből a részletet, így ellentétes értelműnek mutatni azt.
Az általad "részidézett" szövegem elején ugyebár hangsúlyosan azzal indítottam, hogy ÉN NEM VAGYOK ILLETÉKES, DE ILLETÉKESTŐL EZT HALLOTTAM. Két perccel utána rajtam kéred számon, amire mások mondásaként hivatkoztam, hangsúlyozva, hogy én nem tudom, hogy úgy van-e. Miután jeleztem, hogy nem én mondtam, nem is vagyok illetékes mondani, illetékesek mondták, te rajtam cáfolod, mintha én mondtam volna. Ennyit lelkesedésről...

Továbbá, amit a hifi fórumok élő lelkiismerete fererencz is jelez, hangsúlyosan azonos, értsd AZONOS, azaz AZONOS, másképp fogalmazva AZONOS termékeikről volt szó annak fényében, hogy ILLETÉKESEK MONDÁSA(!) szerint azok mindenben azonos termékek, mert azonosan vannak az Amazon azonos szerverparkjában, és azonos hálózati módszerekkel érkeznek ki a világba. ILLETÉKESEK MONDÁSA SZERINT, MIVEL ÉN NEM VAGYOK ILLETÉKES MONDANI - értsd, ÉN NEM TUDOM, de hozzáértő illetékes szerint úgy van, ahogy hivatkoztam rá.

És ha (HA!!!) igaza van az általam hivatkozott illetékeseknek, akkor persze neked (se) abban sincs igazad, hogy az AZONOS TERMÉKEIKBEN más tömörítési eljárást alkalmaznak, mert akkor ők nem alkalmaznak semmilyen tömörítési eljárást, csak az informatikai háttérről gondoskodnak avégett, hogy az Amazon szerverről A KIADÓ ÁLTAL odadobott fájl elmenjen az azt kérő fogyasztó készüléke felé - én nem tudom, hogy így van-e, velem szemben ebben nem tudsz ellentmondani, mert nem én mondtam, hanem illetékes hozzáértőket idéztem, akik például éppen az általad most is közölteket is mint általános tévhitet cáfolták a mondásukkal, ha (HA!!!) igazuk van. Nem mellesleg engem is cáfoltak (ha igazuk van!!!), mert én is úgy "tudtam" addig, ahogyan a közvélekedés.

Szerk.: Ráadásul még a kiragadott idézetben is hangsúlyosan aszerint fogalmaztam, hogy "hangminőségkülönbségről szóló általános tapasztalásokat vagy tapasztalni véléseket.". VAGY TAPASZTALNI VÉLÉSEKET. Hiszen hiszen.

[fererencz]

...és ezért is kicsit nehéz magyarázni a köztük, például a Tidal és a Spotify azonos streamtermékei között levő jelentős általános hangminőségkülönbségről szóló általános tapasztalásokat vagy tapasztalni véléseket.

Fennen hangoztatott szakmai előmeneteledre némi árnyékot vet a tény, hogy a két említett szolgáltató erősen más tömörítési eljárást és adatformátumot alkalmaz, tehát pont ezeknél logikátlan vitatni a hallható különbségeket. No de az én lelkesedésem eddig tartott.

Elírás lehet, azonos termékre gondolt gondolom, vagyis pl egyformán losless. Lehet, hogy tévedek, de így látom értelmét.

[pärt]

"Vadász, vadász, te...jársz ide"

[Luxor Audio]

...és ezért is kicsit nehéz magyarázni a köztük, például a Tidal és a Spotify azonos streamtermékei között levő jelentős általános hangminőségkülönbségről szóló általános tapasztalásokat vagy tapasztalni véléseket.

Fennen hangoztatott szakmai előmeneteledre némi árnyékot vet a tény, hogy a két említett szolgáltató erősen más tömörítési eljárást és adatformátumot alkalmaz, tehát pont ezeknél logikátlan vitatni a hallható különbségeket. No de az én lelkesedésem eddig tartott.

[Aszpirin]

Na akkor szerintem most maradjunk ennyiben.
( )

[kammerer]

Még inkább azért megy alapból UDP-n, mert a zenestreamszolgáltatóktól való zenestreamelés ugyebár egy real time ("lejátszási") folyamat.

Én a kezdetektől úgy érzem, hogy kevered az élő közvetítéseket a zenei streaming szolgáltatásokkal, ebből fakad a félreértelmezésed.

Előbbinél valóban real-time folyamat zajlik UDP protokollal és kevésbé érdekes, hogy némi adat elveszik, fontosabb a műsor folyamatossága és időzítése. Sok külföldi TV sportközvetítésen dolgoztam. Ott ha elindult a meccs, a stream jött, nem volt rá hatásunk, igazodnunk kellett hozzá és ha a vonal megszakadt, akkor bizony lemaradtunk a gólról.

A zenei streaming viszont nem ilyen, ott nem a szerver a lejátszóeszköz, hanem a saját készüléked, ami a szervertől kéri a lejátszandó adatokat. A muzsika addig meg sem szólal, míg az első adatcsomagok meg nem érkeznek és a pufferelt mennyiség nem ér el egy szintet. Gyakran a teljes tracket pufferelik, majd lejátszás közben alig van adatforgalom a szerver és a lejátszó között, ami ugye kizárja a real-time folyamatot. Az errefelé sem ismeretlen Pink Faun cég odáig megy el az audio PC-inél használt Stylus szoftverrel, hogy a teljes albumot / lejátszási listát puffereli, letölti és helyben tárolja (átmenetileg) lejátszás előtt, majd bontja a vonalat, kikapcsolja a gép nagy részét (még a hálókártyát is!), ami nem szükséges a kijátszáshoz.

Kb ez történik akkor is, ha egy albumot a streaming szolgáltatásban kedvencnek jelölünk off-line hallgatáshoz, a műsor akkor is helyi (tartós) tárolóból kerül kijátszásra, a központi szervertől ilyenkor csak metaadatok érkeznek, meg lefut néhány autentikációs és autorizációs folyamat.

Aki autózott már gyenge térerőben és közben próbált stream forrásból zenét hallgatni (velem többször is előfordult mostanában az Alföldön), az megtapasztalhatta, hogy ha nem érkezik kellő adat, a lejátszás minősége nem romlik, hanem el sem indul. A realtime stream / élő közvetítés másként viselkedik, az nem áll meg, tőlünk függetlenül zajlik, maximum kockásodik, szaggat a kép, kimarad a hang, stb., ha gyenge a kapcsolat, de tolja rendületlenül.

A hozzáértőktől bocsánatot kérek a konyhai nyelvezet miatt! Nem szakterületem a téma, szóval nem bántódom meg, ha kijavítanak.

Én nem keverek semmit. Sőt én kértem, kezdettől, hogy ne keverjünk ide semmi mást, a zenestreamszolgáltatók zenestreamszolgáltatásáról volt szó - cables ismerősének eredeti felvetésében is.

"A hozzáértőktől bocsánatot kérek a konyhai nyelvezet miatt! Nem szakterületem a téma..."
Nekem ellenben szakterületem a broadcasting (is), és ha Diagnet nem használná ki önös céljaira, utalnék arra is, hogy diplomám is van ebből is, ezért csak anyit jelzek, hogy gyakorlatom is van ebben is - operatőr, műsorszerkesztő, (élő)adáslebonyolító technikus és adásrendező... Mindez persze mindegy, hiszen nem tartozik ide ez a téma sem.
Ha Diagnet nem használná ki, arra is utalnék, hogy informatikusi diplomám is van, és kiegészítő képzéseim is, ezért csak arra utalok, hogy gyakorlatom is van e téren is. Hálózati informatika terén is. Mindez persze szintén mindegy, nem szoktam tekintélyérvhez folyamodni, csak jelzem, hogy az Aszpirin által elindított módszer, azaz a kompetenciám előre megkérdőjelezése (mint internetközhelyes "érvelési hiba") nem alkalmas a helyzetre.
De mi soha nem értettük egymást ilyesféle széles témakörökben, mitől értenénk éppen most.
Szerk.: de te legalább kommunikálsz, mint általában is. Van mire válaszolnom.

[Alex_Aston]

Kis pontosításokkal erről lenne szó - persze "sejtem", hogy a magad részéről élesen ironikus hangnemben írtad az összegzést, hehe.

Ha még az iróniát is meg akarod magyarázni, akkor ennyi erővel a belső hangokkal is nyugodtan vitába szállhatnál.

[kammerer]

Félek, a polémia elsődleges oka az, hogy esetleg elbeszélünk egymás mellett, ezért foglaljuk össze, mit is tudtunk meg a streaming architektúráját, működését illetően!
Az olyan elterjedt streaming szolgáltatók esetén, mint a Spotify, vagy a Tidal, a nagy valószínűséggel Amazonnál futó szerverek egyfajta "digitális futóműként" "lejátsszák" a tárolt tartalmat, amely így "stream" aka "hullám" aka "jelfolyam" aka "hangjel" formájában csomagocskákra bontva, real-time kerülnek továbbításra a hibajavítás híján megbízhatatlan, cserébe a kisebb overhead miatt alacsonyabb sávszélesség igényű UDP protokoll (esetleg annak némiképp TCP-izált változatának) alkalmazásával az otthoni rendszereink felé, ahol már csak a "komparátor" által táplált DAC szükséges a lejátszáshoz. Bár úgy tűnik, hogy az utóbbi időben egyre inkább elterjed a hálózati lassulások által esetlegesen okozott kimaradások kivédésére a megfelelő interfésszel ellátott puffermemória, amely az architektúrában talán a "komparátor" előtt (?) helyezkedik el.
A streaming hangminőségének időszakosan tapasztalható romlásáért a tökéletlen UDP protokoll által okozott adatvesztést okolhatjuk.
Remélem, semmit nem hagytam ki!

Kis pontosításokkal erről lenne szó - persze "sejtem", hogy a magad részéről élesen ironikus hangnemben írtad az összegzést, hehe.

Kis pontosítások:
"Az olyan elterjedt streaming szolgáltatók esetén, mint a Spotify, vagy a Tidal, a nagy valószínűséggel Amazonnál futó szerverek"
Elvileg biztosan az Amazon szerverein. Én nem vagyok illetékes e téren, de illetékes bennfentes(ek) azt mondta(ák) épp a minap, hogy ezek a fő elterjedt szolgáltatók egyaránt az Amazon szerverein vannak, és streamelődnek azonos hálózatban azonos módon, és - kis sarkítással - a zenestreamszolgáltató csak a vevőkkel való információs kommunikáció irányítását, weblap fenntartását, a lekérések informatikai kezelését végzi (és ezért is kicsit nehéz magyarázni a köztük, például a Tidal és a Spotify azonos streamtermékei között levő jelentős általános hangminőségkülönbségről szóló általános tapasztalásokat vagy tapasztalni véléseket.)

"ahol már csak a "komparátor" által táplált DAC szükséges a lejátszáshoz."
Ugyebár az otthoni streamer értelmű készülék(rész)re is szükség van, mint a streamkapcsolat kezelőjére. Ezt kihagytad. A hálózati lejátszó a tőle nagyon messzire kihelyezett közösségi "futóművel".

"puffermemória, amely az architektúrában talán a "komparátor" előtt (?) helyezkedik el."
A tárgyalt feladathoz nyilván a komparátor elé teendő, hiszen a stream kezelésében vesz részt, értelmileg a streamer készülékrész része. (A komparátor mögött esetleg leendő puffermemória már inkább DAC készülékbelsői feladatokat végezne.)

"A streaming hangminőségének időszakosan tapasztalható romlásáért a tökéletlen UDP protokoll által okozott adatvesztést okolhatjuk."
Azt is okolhatjuk. Is. Már hogyha egyáltalán tényleg van ilyen hangminőségváltozás adott szolgáltató adott streamfájljának streamelésében. (Értsd én nem állítottam, hogy bizonyosan van ilyen hallható változékonyság, mindössze megvédtem más hifisták erről szóló hifista tapasztalatának lehetségességét, sőt látszólagos logikusságát. Én azon az állításon lepődnék meg, hogy nincs ilyen hangminőségváltozás.)

[Luxor Audio]

Még inkább azért megy alapból UDP-n, mert a zenestreamszolgáltatóktól való zenestreamelés ugyebár egy real time ("lejátszási") folyamat.

Én a kezdetektől úgy érzem, hogy kevered az élő közvetítéseket a zenei streaming szolgáltatásokkal, ebből fakad a félreértelmezésed.

Előbbinél valóban real-time folyamat zajlik UDP protokollal és kevésbé érdekes, hogy némi adat elveszik, fontosabb a műsor folyamatossága és időzítése. Sok külföldi TV sportközvetítésen dolgoztam. Ott ha elindult a meccs, a stream jött, nem volt rá hatásunk, igazodnunk kellett hozzá és ha a vonal megszakadt, akkor bizony lemaradtunk a gólról.

A zenei streaming viszont nem ilyen, ott nem a szerver a lejátszóeszköz, hanem a saját készüléked, ami a szervertől kéri a lejátszandó adatokat. A muzsika addig meg sem szólal, míg az első adatcsomagok meg nem érkeznek és a pufferelt mennyiség nem ér el egy szintet. Gyakran a teljes tracket pufferelik, majd lejátszás közben alig van adatforgalom a szerver és a lejátszó között, ami ugye kizárja a real-time folyamatot. Az errefelé sem ismeretlen Pink Faun cég odáig megy el az audio PC-inél használt Stylus szoftverrel, hogy a teljes albumot / lejátszási listát puffereli, letölti és helyben tárolja (átmenetileg) lejátszás előtt, majd bontja a vonalat, kikapcsolja a gép nagy részét (még a hálókártyát is!), ami nem szükséges a kijátszáshoz.

Kb ez történik akkor is, ha egy albumot a streaming szolgáltatásban kedvencnek jelölünk off-line hallgatáshoz, a műsor akkor is helyi (tartós) tárolóból kerül kijátszásra, a központi szervertől ilyenkor csak metaadatok érkeznek, meg lefut néhány autentikációs és autorizációs folyamat.

Aki autózott már gyenge térerőben és közben próbált stream forrásból zenét hallgatni (velem többször is előfordult mostanában az Alföldön), az megtapasztalhatta, hogy ha nem érkezik kellő adat, a lejátszás minősége nem romlik, hanem el sem indul. A realtime stream / élő közvetítés másként viselkedik, az nem áll meg, tőlünk függetlenül zajlik, maximum kockásodik, szaggat a kép, kimarad a hang, stb., ha gyenge a kapcsolat, de tolja rendületlenül.

A hozzáértőktől bocsánatot kérek a konyhai nyelvezet miatt! Nem szakterületem a téma, szóval nem bántódom meg, ha kijavítanak.

[Aszpirin]

Félek, a polémia elsődleges oka az, hogy esetleg elbeszélünk egymás mellett, ezért foglaljuk össze, mit is tudtunk meg a streaming architektúráját, működését illetően!
Az olyan elterjedt streaming szolgáltatók esetén, mint a Spotify, vagy a Tidal, a nagy valószínűséggel Amazonnál futó szerverek egyfajta "digitális futóműként" "lejátsszák" a tárolt tartalmat, amely így "stream" aka "hullám" aka "jelfolyam" aka "hangjel" formájában csomagocskákra bontva, real-time kerülnek továbbításra a hibajavítás híján megbízhatatlan, cserébe a kisebb overhead miatt alacsonyabb sávszélesség igényű UDP protokoll (esetleg annak némiképp TCP-izált változatának) alkalmazásával az otthoni rendszereink felé, ahol már csak a "komparátor" által táplált DAC szükséges a lejátszáshoz. Bár úgy tűnik, hogy az utóbbi időben egyre inkább elterjed a hálózati lassulások által esetlegesen okozott kimaradások kivédésére a megfelelő interfésszel ellátott puffermemória, amely az architektúrában talán a "komparátor" előtt (?) helyezkedik el.
A streaming hangminőségének időszakosan tapasztalható romlásáért a tökéletlen UDP protokoll által okozott adatvesztést okolhatjuk.
Remélem, semmit nem hagytam ki!

Egyet kifelejtettél: hogy az internet összeomlana, ha mindez valódi TCP-n menne

[fererencz]

Ha valaki esetleg nem ismerné, miheztartás végett információ.

Nem csak a Prohardveren, a magyar interneten több helyén és saját blog(ok)ban a Void/S B brand vezeti azon ultraantihifista mozgolódást, amelynek eszmerendszerében még a hangszórókábelek hangminősége között se lehet különbség.

OFF

A sátán maga is lehetne, de a neve emlegetése mellett próbálod rossz színben feltűntetni. Vagyis ez már szinte "érdem", reklám is lehet számára.
Remélem a valós munkásságával is tisztában vagy, nem csak az emlegetett "munkásságával".

[juliush]

Félek, a polémia elsődleges oka az, hogy esetleg elbeszélünk egymás mellett, ezért foglaljuk össze, mit is tudtunk meg a streaming architektúráját, működését illetően!
Az olyan elterjedt streaming szolgáltatók esetén, mint a Spotify, vagy a Tidal, a nagy valószínűséggel Amazonnál futó szerverek egyfajta "digitális futóműként" "lejátsszák" a tárolt tartalmat, amely így "stream" aka "hullám" aka "jelfolyam" aka "hangjel" formájában csomagocskákra bontva, real-time kerülnek továbbításra a hibajavítás híján megbízhatatlan, cserébe a kisebb overhead miatt alacsonyabb sávszélesség igényű UDP protokoll (esetleg annak némiképp TCP-izált változatának) alkalmazásával az otthoni rendszereink felé, ahol már csak a "komparátor" által táplált DAC szükséges a lejátszáshoz. Bár úgy tűnik, hogy az utóbbi időben egyre inkább elterjed a hálózati lassulások által esetlegesen okozott kimaradások kivédésére a megfelelő interfésszel ellátott puffermemória, amely az architektúrában talán a "komparátor" előtt (?) helyezkedik el.
A streaming hangminőségének időszakosan tapasztalható romlásáért a tökéletlen UDP protokoll által okozott adatvesztést okolhatjuk.
Remélem, semmit nem hagytam ki!