Hálózati audio lejátszók

[Rag]

Sziasztok!

Ebben esetleg valaki tud segíteni?

Sziasztok!

Segítséget szeretnék kérni. Újra kellett telepítenem a Volumio-t a Raspberry-mre, mert leállt és nem reagált semmire.

DE nem tudom hogyan kell pontosan beállítani a Nas-om címét. A meghajtó hozzáadásánál megtalálja program a NAS-t, ami egy D-Link DNS-323, de az utvonalnál már problémája van. A "Volume_1" nem működik. Egyszer már megoldottam, nem nem emlékszem rá hogyan pontosan. Valahogy máshogy kell az útvonalat megadni, de a linux-os útvonal sem jó mnt/HD_a2.

Használ valaki DNS nas-t Volumio-val?

[SSS]

fyi érdekes megoldás

https://sites.google.com/a/architekturk ... ources/x-6

[Kabóca]

Köszönöm

Szívesen. Ma az Onkyo lejátszóm frissített. Szerintem hamarosan lesz a Pioneer készülékekre is új, a két márka egy kézben van, egy időben szoktak frissülni.

[Alamo]

Köszönöm

Sziasztok !

Remélem tud valaki segíteni !
Pioneer N50AE készüléken van.
Szeretném frissíteni,de nem találom a menüben a lehetőséget .Régebben frissítettem
Lett reszetelve .
Valaki tudna segíteni megköszönném !!
Üdv Alamo

https://www.pioneer-audiovisual.eu/de/f ... date/15498
Csak akkor jelenik meg a menüben a frissítés lehetősége ha a rajtalévőtől újabb firmwaret érzékel a készülék az internetről vagy az USB portról.

[Kabóca]

Sziasztok !

Remélem tud valaki segíteni !
Pioneer N50AE készüléken van.
Szeretném frissíteni,de nem találom a menüben a lehetőséget .Régebben frissítettem
Lett reszetelve .
Valaki tudna segíteni megköszönném !!
Üdv Alamo

https://www.pioneer-audiovisual.eu/de/f ... date/15498
Csak akkor jelenik meg a menüben a frissítés lehetősége ha a rajtalévőtől újabb firmwaret érzékel a készülék az internetről vagy az USB portról.

[wwwolfman]

Sziasztok !

Remélem tud valaki segíteni !
Pioneer N50AE készüléken van.
Szeretném frissíteni,de nem találom a menüben a lehetőséget .Régebben frissítettem
Lett reszetelve .
Valaki tudna segíteni megköszönném !!
Üdv Alamo

https://www.pioneer-audiovisual.eu/site ... UCTION.pdf


úgy kettő perc volt...

[Alamo]

Sziasztok !

Remélem tud valaki segíteni !
Pioneer N50AE készüléken van.
Szeretném frissíteni,de nem találom a menüben a lehetőséget .Régebben frissítettem
Lett reszetelve .
Valaki tudna segíteni megköszönném !!
Üdv Alamo

[alto]

Bocsánat, de kétségbeejtő marhaság amit írsz. A TCP/IP hibajavító algoritmusa és maga a protokoll gondoskodik arról, hogy minden csomag bithelyes legyen, ha ez nem megy, akkor nem jön semmi. A lejátszókban általában elég méretes buffer gondoskodik arról, hogy hálózati probléma esetén ne szakadozzon a lejátszás. Ha annyira problémás a hálózati kapcsolat, akkor a buffer kiürülget, a lejátszás meg szakadozik, de nincs olyan, hogy a lejátszó "kikalkulál" valamit, ha kiürült a buffer.

Vélhetően összekevered az Audio CD működésével ezt a dolgot, ott valóban az van, hogy ha az olvasó nem tudja eldönteni a CD-n lévő pitről hogy 0 vagy 1, és az Audio CD szabvány sajnálatosan gyengére megalkotott hibajavító algoritmusa sem jut ezzel dűlőre, akkor a folyamatos lejátszás érdekében a CD lejátszó "odahazudik" valamit. Ez is egyfajta jitter, túl sok ilyen rontja a hangminőséget, még több pedig pattogást, szakadozást okoz.

Azt hiszem ez még mindig nem a teljes kép. Amiről TCP/IP szintjén írsz, valóban igaz, ugyanakkor nem tartom kizártnak, hogy a TCI/IP layer fölött alkalmazhatnak hibajavító kódolást/dekódolást az elveszett információ bitek pótlására.

Vegyük észre, hogy az a helyzet, amiről a hálózati adattovábbítás során írtál, vagyis a TCP/IP hibajavítása ellenére véglegesen elveszettnek tűnő bitek esete innentől tökéletesen megegyezik mondjuk a CD vagy egyéb fizikai médiumok sérüléséből adódó bitvesztéssel! Ezek helyreállítása még mindig lehetséges lehet olyan kódolási/dekódolási eljárások alkalmazásával, mint a CD esetén is alkalmazott ún. Reed-Solomon kódolás, ami ellentétben a fent idézett véleményeddel egy igen hatékony és robusztus algoritmus, a CD esetén alkalmazott CIRC eljárás esetén gyakorlatilag 4000 bit kiesése (2,4mm-nyi pithiány a lemezen!!!) tökéletesen helyreállítható!

Ennél nagyobb kiesés esetén jöhet a hiányzó információ interpoláció alkalmazásával történő pótlása, amelynek már hallható hatása lehet, bár hozzá kell tennem, hogy a CIRC áldásos hatása ebben is érvényesül, mivel a algoritmus jellegénél fogva a nagy kiesést kisebb hibákra szórja szét, amellyel már jobban tud boldogulni az interpoláció, amely egyébként intelligens digitális szűrőkkel ugyancsak meglehetősen hatékonyan tud helyreállítani.
Ez az interpoláció nem jitter-jellegű (értsd time-base) probléma.

Nem tudom, hogy a multimédia-célú hálózati protokollok esetén alkalmaznak-e ilyesmit, de nagyon meg lennék lepődve, ha nem tennék!

Az Audio CD-k eseten alkalmazott Reed Solomont kódolást lehet hatékonynak tekinteni, de kérdés hogy mihez képest. A CD-Rom szabvány például a Red Bookhoz képest sokkal erősebb hibajavítást alkalmaz, ami érthető is, adatfileok esetén ugyanis az inerpolációs technika nem jöhet szóba.

A hálózati lejátszók bufferébe minden esetben bithelyesen kerülnek be a csomagok, vagy nem kerülnek be. Ha viszont kiürül a buffer, akkor nincs miből interpolálni, igy fel sem merülhet, hogy majd a lejátszó “kikalkulál” valamit.

[asebestyen]

Mindig megmosolyogtatnak (vagy inkább fel@*|z), az ilyen írások. Enyhe túlzással, földet 20x megkerülő adatcsomagok jönnek meg hibátlanul, a kormányok, multi cégek 1000-10.000km távolságra utaztatják az adataikat amin a létük és fennmaradásuk múlik. Aztán jön a hifista és 1 méterre nem tudja helyesen továbbítani azt a nyamvadt adatcsomagot. Vagy legalábbis ezt gondolja, aztán meg is magyarázza. A többi hívő meg körbebólogatja. Ahova a hifisták beteszik lábukat ott egyből elkezdődik a hit, meg teóriák gyártása.

Tetszetős gondolat, de hidd el, hogy a multimédiás tartalmak otthoni környezetben történő IP-alapú terjesztésében alkalmazott protokollok köszönő viszonyban sincsenek a "kormányok, multi cégek" által használt elképesztően robusztus és redundáns technológiáival, amellyel "1000-10.000km távolságra utaztatják az adataikat amin a létük és fennmaradásuk múlik".
Szóval almát körtével.

Ezek is tetszetős gondolatok, de ez a sztori sokkal egyszerűbb. Itt mindig arról van szó, hogy a Tidal stream akadozik. Az meg nem a helyi hálózat miatt van, mert amikor egy album elkezd akadozni, akkor egy másik, adott esetben nagyobb felbontású meg simán megy, semmi köze az otthoni hálózathoz. Olyan meg nincs, hogy szól, csak a hang minősége ingadozik, vagy szól rendesen, vagy megáll, míg megtelik a buffer, akkor megint elindul.

[juliush]

Mindig megmosolyogtatnak (vagy inkább fel@*|z), az ilyen írások. Enyhe túlzással, földet 20x megkerülő adatcsomagok jönnek meg hibátlanul, a kormányok, multi cégek 1000-10.000km távolságra utaztatják az adataikat amin a létük és fennmaradásuk múlik. Aztán jön a hifista és 1 méterre nem tudja helyesen továbbítani azt a nyamvadt adatcsomagot. Vagy legalábbis ezt gondolja, aztán meg is magyarázza. A többi hívő meg körbebólogatja. Ahova a hifisták beteszik lábukat ott egyből elkezdődik a hit, meg teóriák gyártása.

Tetszetős gondolat, de hidd el, hogy a multimédiás tartalmak otthoni környezetben történő IP-alapú terjesztésében alkalmazott protokollok köszönő viszonyban sincsenek a "kormányok, multi cégek" által használt elképesztően robusztus és redundáns technológiáival, amellyel "1000-10.000km távolságra utaztatják az adataikat amin a létük és fennmaradásuk múlik".
Szóval almát körtével.

[juliush]

Vegyük észre, hogy az a helyzet, amiről a hálózati adattovábbítás során írtál, vagyis a TCP/IP hibajavítása ellenére véglegesen elveszettnek tűnő bitek esete innentől tökéletesen megegyezik mondjuk a CD vagy egyéb fizikai médiumok sérüléséből adódó bitvesztéssel!

Ez így nem értelmezhető. Az RFC793 alapján a bithibás csomagokat a vevőnek el kell dobnia, és újrakérnie. Egyetlen esetben kerülhet hibás adat a lejátszóba, ha a payload és a checksum úgy sérülnek, hogy a hibás checksum megfelel a hibás payloadnak. Ekkor viszont senki sem fogja észrevenni a hibát.

Hát ha a világ összes ideje rendelkezésre állna, akkor ez így is lenne, de a zenelejátszás többé-kevésbé real-time folyamata során a rendelkezésre álló buffer mérete határozza meg, meddig is próbálkozhat újraküldetéssel!

[-KP-]

Mindig megmosolyogtatnak (vagy inkább fel@*|z), az ilyen írások. Enyhe túlzással, földet 20x megkerülő adatcsomagok jönnek meg hibátlanul, a kormányok, multi cégek 1000-10.000km távolságra utaztatják az adataikat amin a létük és fennmaradásuk múlik. Aztán jön a hifista és 1 méterre nem tudja helyesen továbbítani azt a nyamvadt adatcsomagot. Vagy legalábbis ezt gondolja, aztán meg is magyarázza. A többi hívő meg körbebólogatja. Ahova a hifisták beteszik lábukat ott egyből elkezdődik a hit, meg teóriák gyártása.

[Quetz]

Vegyük észre, hogy az a helyzet, amiről a hálózati adattovábbítás során írtál, vagyis a TCP/IP hibajavítása ellenére véglegesen elveszettnek tűnő bitek esete innentől tökéletesen megegyezik mondjuk a CD vagy egyéb fizikai médiumok sérüléséből adódó bitvesztéssel!

Ez így nem értelmezhető. Az RFC793 alapján a bithibás csomagokat a vevőnek el kell dobnia, és újrakérnie. Egyetlen esetben kerülhet hibás adat a lejátszóba, ha a payload és a checksum úgy sérülnek, hogy a hibás checksum megfelel a hibás payloadnak. Ekkor viszont senki sem fogja észrevenni a hibát.

Reliability:

The TCP must recover from data that is damaged, lost, duplicated, or
delivered out of order by the internet communication system. This
is achieved by assigning a sequence number to each octet
transmitted, and requiring a positive acknowledgment (ACK) from the
receiving TCP. If the ACK is not received within a timeout
interval, the data is retransmitted. At the receiver, the sequence
numbers are used to correctly order segments that may be received
out of order and to eliminate duplicates. Damage is handled by
adding a checksum to each segment transmitted, checking it at the
receiver, and discarding damaged segments.

Az application layer, azaz a lejátszó hibajavítást végezhet ha a payload formátumában van checksum. A Flac formátum pl. minden frame-hez rendel crc checksumot. De szerintem ha egy Flac file hibás lesz, akkor az nagy valószínüséggel már a küldő oldalán is az volt.

[juliush]

Bocsánat, de kétségbeejtő marhaság amit írsz. A TCP/IP hibajavító algoritmusa és maga a protokoll gondoskodik arról, hogy minden csomag bithelyes legyen, ha ez nem megy, akkor nem jön semmi. A lejátszókban általában elég méretes buffer gondoskodik arról, hogy hálózati probléma esetén ne szakadozzon a lejátszás. Ha annyira problémás a hálózati kapcsolat, akkor a buffer kiürülget, a lejátszás meg szakadozik, de nincs olyan, hogy a lejátszó "kikalkulál" valamit, ha kiürült a buffer.

Vélhetően összekevered az Audio CD működésével ezt a dolgot, ott valóban az van, hogy ha az olvasó nem tudja eldönteni a CD-n lévő pitről hogy 0 vagy 1, és az Audio CD szabvány sajnálatosan gyengére megalkotott hibajavító algoritmusa sem jut ezzel dűlőre, akkor a folyamatos lejátszás érdekében a CD lejátszó "odahazudik" valamit. Ez is egyfajta jitter, túl sok ilyen rontja a hangminőséget, még több pedig pattogást, szakadozást okoz.

Azt hiszem ez még mindig nem a teljes kép. Amiről TCP/IP szintjén írsz, valóban igaz, ugyanakkor nem tartom kizártnak, hogy a TCI/IP layer fölött alkalmazhatnak hibajavító kódolást/dekódolást az elveszett információ bitek pótlására.

Vegyük észre, hogy az a helyzet, amiről a hálózati adattovábbítás során írtál, vagyis a TCP/IP hibajavítása ellenére véglegesen elveszettnek tűnő bitek esete innentől tökéletesen megegyezik mondjuk a CD vagy egyéb fizikai médiumok sérüléséből adódó bitvesztéssel! Ezek helyreállítása még mindig lehetséges lehet olyan kódolási/dekódolási eljárások alkalmazásával, mint a CD esetén is alkalmazott ún. Reed-Solomon kódolás, ami ellentétben a fent idézett véleményeddel egy igen hatékony és robusztus algoritmus, a CD esetén alkalmazott CIRC eljárás esetén gyakorlatilag 4000 bit kiesése (2,4mm-nyi pithiány a lemezen!!!) tökéletesen helyreállítható!

Ennél nagyobb kiesés esetén jöhet a hiányzó információ interpoláció alkalmazásával történő pótlása, amelynek már hallható hatása lehet, bár hozzá kell tennem, hogy a CIRC áldásos hatása ebben is érvényesül, mivel a algoritmus jellegénél fogva a nagy kiesést kisebb hibákra szórja szét, amellyel már jobban tud boldogulni az interpoláció, amely egyébként intelligens digitális szűrőkkel ugyancsak meglehetősen hatékonyan tud helyreállítani.
Ez az interpoláció nem jitter-jellegű (értsd time-base) probléma.

Nem tudom, hogy a multimédia-célú hálózati protokollok esetén alkalmaznak-e ilyesmit, de nagyon meg lennék lepődve, ha nem tennék!

[alto]

Nyilván a nagyobb sávszélességhez több adat kel mint a gyenge Spotyfy-hoz.Wifi a hifiben csak gyengébb eredményt adhat. Amióta kábellel csatlakozom azóta elégedett vagyok a Tidal minőségével.

Valaki kicsit kitudná fejteni, hogy ha pl. wifi-n keresztül hallgatunk Tidal-t, az miért rosszabb mintha háló kábelen keresztül tennénk mindezt? Az adott számot elég gyorsan teljesen letölti és úgy játsza ki nem?

Erről két blogbejegyzésemben részletesen írok...
https://audiofilblog.blogspot.com/2018/ ... -cat7.html
A lényeg, hogy ha a digitális jelcsomagok nem érkeznek elég gyorsan a lejátszóba (pl. wifi-s lejátszás esetén), akkor a lejátszó kikalkulál egy szerinte korrekt jelcsomagot, de lehet, hogy az nem fedi le a valóságot. Kipróbáltam wifi-n és kábellel, a különbség a hangminőségben igen jelentős.
Egy korszerű, és gyors CAT6, vagy CAT7 kábellel meglepően komoly minőségjavulás érhető el, főleg a lejátszó előtt lényeges a jó kábel....

Bocsánat, de kétségbeejtő marhaság amit írsz. A TCP/IP hibajavító algoritmusa és maga a protokoll gondoskodik arról, hogy minden csomag bithelyes legyen, ha ez nem megy, akkor nem jön semmi. A lejátszókban általában elég méretes buffer gondoskodik arról, hogy hálózati probléma esetén ne szakadozzon a lejátszás. Ha annyira problémás a hálózati kapcsolat, akkor a buffer kiürülget, a lejátszás meg szakadozik, de nincs olyan, hogy a lejátszó "kikalkulál" valamit, ha kiürült a buffer.

Vélhetően összekevered az Audio CD működésével ezt a dolgot, ott valóban az van, hogy ha az olvasó nem tudja eldönteni a CD-n lévő pitről hogy 0 vagy 1, és az Audio CD szabvány sajnálatosan gyengére megalkotott hibajavító algoritmusa sem jut ezzel dűlőre, akkor a folyamatos lejátszás érdekében a CD lejátszó "odahazudik" valamit. Ez is egyfajta jitter, túl sok ilyen rontja a hangminőséget, még több pedig pattogást, szakadozást okoz.

Mindentől függetlenül valóban lehet hangzásbeli különbség a wifis és kábeles hálózati lejátszás esetén, de ennek okozója biztos nem az, amit leírtál.

[AST]

Erről két blogbejegyzésemben részletesen írok...
https://audiofilblog.blogspot.com/2018/ ... -cat7.html
A lényeg, hogy ha a digitális jelcsomagok nem érkeznek elég gyorsan a lejátszóba (pl. wifi-s lejátszás esetén), akkor a lejátszó kikalkulál egy szerinte korrekt jelcsomagot, de lehet, hogy az nem fedi le a valóságot. Kipróbáltam wifi-n és kábellel, a különbség a hangminőségben igen jelentős.
Egy korszerű, és gyors CAT6, vagy CAT7 kábellel meglepően komoly minőségjavulás érhető el, főleg a lejátszó előtt lényeges a jó kábel....
[/quote]
Lehetséges, hogy WIFI be volt kapcsolva a gépeden és a gép kalkulálta ki helyetted ezt az írást, aztán így sikerült.

[dbrnsk]

[asebestyen]

Erről két blogbejegyzésemben részletesen írok...
https://audiofilblog.blogspot.com/2018/ ... -cat7.html
A lényeg, hogy ha a digitális jelcsomagok nem érkeznek elég gyorsan a lejátszóba (pl. wifi-s lejátszás esetén), akkor a lejátszó kikalkulál egy szerinte korrekt jelcsomagot, de lehet, hogy az nem fedi le a valóságot. Kipróbáltam wifi-n és kábellel, a különbség a hangminőségben igen jelentős.
Egy korszerű, és gyors CAT6, vagy CAT7 kábellel meglepően komoly minőségjavulás érhető el, főleg a lejátszó előtt lényeges a jó kábel....

Az, kikalkulál..., vagy kisorsolják Kenón...

[R_Andras]

De szerintem a Tidal-al is van baj, mert nálam pl. Spotify premium sokkal problémamentesen fut.

Nyilván a nagyobb sávszélességhez több adat kel mint a gyenge Spotyfy-hoz.Wifi a hifiben csak gyengébb eredményt adhat. Amióta kábellel csatlakozom azóta elégedett vagyok a Tidal minőségével.

Valaki kicsit kitudná fejteni, hogy ha pl. wifi-n keresztül hallgatunk Tidal-t, az miért rosszabb mintha háló kábelen keresztül tennénk mindezt? Az adott számot elég gyorsan teljesen letölti és úgy játsza ki nem?

Erről két blogbejegyzésemben részletesen írok...
https://audiofilblog.blogspot.com/2018/ ... -cat7.html
A lényeg, hogy ha a digitális jelcsomagok nem érkeznek elég gyorsan a lejátszóba (pl. wifi-s lejátszás esetén), akkor a lejátszó kikalkulál egy szerinte korrekt jelcsomagot, de lehet, hogy az nem fedi le a valóságot. Kipróbáltam wifi-n és kábellel, a különbség a hangminőségben igen jelentős.
Egy korszerű, és gyors CAT6, vagy CAT7 kábellel meglepően komoly minőségjavulás érhető el, főleg a lejátszó előtt lényeges a jó kábel....

[Rag]

Sziasztok!

Segítséget szeretnék kérni. Újra kellett telepítenem a Volumio-t a Raspberry-mre, mert leállt és nem reagált semmire.

DE nem tudom hogyan kell pontosan beállítani a Nas-om címét. A meghajtó hozzáadásánál megtalálja program a NAS-t, ami egy D-Link DNS-323, de az utvonalnál már problémája van. A "Volume_1" nem működik. Egyszer már megoldottam, nem nem emlékszem rá hogyan pontosan. Valahogy máshogy kell az útvonalat megadni, de a linux-os útvonal sem jó mnt/HD_a2.

Használ valaki DNS nas-t Volumio-val?

[Aszpirin]

De szerintem a Tidal-al is van baj, mert nálam pl. Spotify premium sokkal problémamentesen fut.

Nyilván a nagyobb sávszélességhez több adat kel mint a gyenge Spotyfy-hoz.Wifi a hifiben csak gyengébb eredményt adhat. Amióta kábellel csatlakozom azóta elégedett vagyok a Tidal minőségével.

Valaki kicsit kitudná fejteni, hogy ha pl. wifi-n keresztül hallgatunk Tidal-t, az miért rosszabb mintha háló kábelen keresztül tennénk mindezt? Az adott számot elég gyorsan teljesen letölti és úgy játsza ki nem?

Ha ugyanazt a sávszélességet biztosítja, akkor nem rosszabb. Valószínű, hogy még jobb is.
Hosszabb magyarázat itt: http://www.avx.hu/forum/viewtopic.php?f ... 5#p2289485

[Kabóca]

Én egy 2-3 éves Asus tabletet vettem a Tidal használatára, amin csak ez megy, nem ezzel nezetek, hanem egy laptoppal. Elindítom a tableten a zent,majd félrerakom, és csak akkor nyúlok hozzá, ha lejárt az album, és újat kell indítanom. Az utolsó lemeznél pedig ahogy elindult a lejátszás rögtön ki is kapcsolom a tabletet, a lejátszás meg megy tovább.

Kikapcsolt készülékről nincs lejátszás, szerintem egy Chromecast kompatibilis eszközről szól a zene és a tablet ilyenkor szinte csak távirányítókén funkcionál, egy kiválasztott album indítása után valóban kikacsolható, ettől függetlenül szól tovább.

Persze, de azt írtam is korábban, hogy egy Onkyo hálózati lejátszóm van.

Akkor jó, már azt hittem további leépítések történtek a rendszeredben.

[ludy]

Köszönöm a tanácsokat,végig probálom ezeket,bele érve hogy a szolgáltatoval is beszélek.

[Kabóca]

Én egy 2-3 éves Asus tabletet vettem a Tidal használatára, amin csak ez megy, nem ezzel nezetek, hanem egy laptoppal. Elindítom a tableten a zent,majd félrerakom, és csak akkor nyúlok hozzá, ha lejárt az album, és újat kell indítanom. Az utolsó lemeznél pedig ahogy elindult a lejátszás rögtön ki is kapcsolom a tabletet, a lejátszás meg megy tovább.

Kikapcsolt készülékről nincs lejátszás, szerintem egy Chromecast kompatibilis eszközről szól a zene és a tablet ilyenkor szinte csak távirányítókén funkcionál, egy kiválasztott album indítása után valóban kikacsolható, ettől függetlenül szól tovább.

[SSS]

Valaki kicsit kitudná fejteni, hogy ha pl. wifi-n keresztül hallgatunk Tidal-t, az miért rosszabb mintha háló kábelen keresztül tennénk mindezt? Az adott számot elég gyorsan teljesen letölti és úgy játsza ki nem?

na ebből megint arra jöttem rá, hogy nagyon hülye vagyok a technológiai részéhez a dolognak
elvileg egyébként valóban simán le kellene tölteni előbb, ilyenkor valószínű az történik, hogy nem tölti le, csak egy darabig jut, és ha idő közben nem sikerül további anyagot letölteni akkor megáll az adott ponton. De remél van hozzáértőbb aki jobban érti ezt az n laikus okoskodásomnál.