Apple számítógépes zenehallgatáshoz

[kaef2]

...Ha nem megfelelő a leátszási lánc további eleme - és akkor tegyük hozzá: ahhoz, amit kap a stúdióból - akkor a lejátszó általi konvertálgatás még férjen bele a bithelyességbe. A probléma ezzel épp csak az, hogy bármilyen konverziót alkalmazol, a bithelyességet már nem tudod értelmezni.
Tehát ha valóban purista elveket vall valaki, akkor nem nyűl hozzá a forráshoz, kivéve ami feltétlenül szükséges. Vannak dolgok, amiket én nem számolnék bithelyesség-elrontónak, ezek közös tulajdonsága, hogy az eredeti bitfolyam bitre pontosan rvisszaállítható belőlük:
- FLAC-ból az "eredeti" PCM visszaállítása
- a DSD bitfolyam DoP transzportcsomagokba pakolása
- PCM bizfolyam S/PDIF vagy AEU/EBU transzportcsomagokba pakolása
- 16 bites PCM 24-bitessé konvertálása a DAC számára nyolc darab alacsony helyiértékű NULLA bit hozzáadásával
- HATÁRESET, de már NAGYON rezeg a léc: a mintavételezési frekvencia az eredeti egész számú többszörösére való konvertálása oly módon, hogy az eredeti minták közé interpolált mintákat szúrnak be (de az eredeti bitfolyam jól azonosíthatóan és visszaállíthatóan megmarad)
Minden egyéb, pl PVM-DSD konverzió vagy pl 44.0 - 96 KHz konverzió semmilyen módon nem számít az én felfogásomban bithelyesnek.

De azt hiszem ez kissé filozófiai kérdés is, és figyeld meg, hogy én nálad is tovább mentem eredetileg...

Fura dolog ez a "bithelyesség"! Ha szigorúan architektúrálisan nézzük, akkor arról beszélünk, hogy van egy digitális távközlési csatornánk, amelynek a végén a "Vevő" bitről-bitre pontosan helyesen helyre tudja állítani az "Adó" oldalán bekerült információt.
A kérdés, hogy az audio lejátszó rendszereink melyik pontjára mutatunk, hogy "Adó", és melyikre, hogy "Vevő".
Ha a "puritánságot" akarnánk kimaxolni, akkor az "Adónak" a zenei információ tárolását végző médiumból kiolvasó és továbbító elemet kellene tekinteni, "Vevőnek" pedig a chip belsejében, vagy diszkrét elemekből felépített digitális/analóg átalakítást fizikailag kivitelező áramkört tápláló puffer kimenetét.
Már a mostani filozófia is sántít a puritanizmus szemszögéből, mikor a "Vevőként" a DAC eszköz bemeneti portját azonosítjuk, és figyelmen kívül hagyjuk a belsejében végrehajtandó transzformációkat a bpplay által addig a pontig bithelyesen továbbított információn.
Azokat az átalakításokat, amelyeket adott esetben épp a bpplay előtt is kivitelezhetnénk, sokkal hatékonyabban, kevesebb káros környezetei hatással, így váltva ki a DAC-ban végrehajtandó transzformáció szükségességét, vagy legalábbis csökkentve annak negatív hatását.
Vegyük észre, hogy a "bithelyesség" pusztán nómenklatúra, mint fizikai alapelv a gyakorlatban korlátozott a kivitelezése! Ugyanakkor sokan a jóság biztosítékaként tekintenek rá.

Amitől egyébként tartok Feri kísérletével kapcsolatban az, hogy annak ellenére, hogy Ő rendkívül konzekvensen kommunikálja az egész kísérlet edukációs jellegét, elutasítja a feltétlen "jobb hangra" törekvést, ezt a hobbit mélyen átitatja a bizonyos technológiai megoldások köré épített "kultusz", és nem adok sok időt annak, hogy megjelenjenek a "megtért" hívők, akik a bpplay puritanizmusában a tökéletesség biztosítékát, vagy legalábbis a jobb ígéretét látják, és az "audiofil" közösségen belül egyfajta "titkos tippként" fog terjedni, anélkül, hogy a megfelelő kontextusban kezelnék.
Ami az én olvasatomban az, hogy a puritanizmus az információ digitális formában történő tárolása, továbbítása, feldolgozása, és végül konverziója szempontjából óhatatlanul kompromisszumokkal jár. Ennek a folyamatnak és rendszernek egy bizonyos szakaszára készített Feri egy remek kis eszközt, amellyel a hatások tetten érhetők, de attól, hogy ezen a szakaszon a puritanizmusra törekedünk, a teljes kép még sokkal árnyaltabb lehet, és az eredmény sem feltétlenül javulás.
De lehet, hogy csak kiábrándult vagyok már, és tévedek.

Ahhoz, hogy a leírtakat maradéktalanul teljesíteni tudjuk hardvert is kellene fejleszteni sajnos. A DAC-ok többsége nem ad lehetőséget csak szoftveres alapon arra, hogy közvetlenül a beépített pufferekkel kommunikáljunk. Ha valaki megfinanszírozza, meg lenne hozzá a hazai tervezői tehetség, lehetne valószínűleg ilyen lejátszó/ DAC kombót csinálni.

Az egész kísérletnek az is célja volt, hogy közben mikroszkópikus léptékben analizálva az útvonalakat, megismerjük, hogy mi történik lejátszáskor. Ha csak annyit elértem, hogy páran elgondolkoznak ezen, már az is valami.

Ha ráadásul az alkalmazás még jól is szól, az sem olyan nagy baj.

[juliush]

...Ha nem megfelelő a leátszási lánc további eleme - és akkor tegyük hozzá: ahhoz, amit kap a stúdióból - akkor a lejátszó általi konvertálgatás még férjen bele a bithelyességbe. A probléma ezzel épp csak az, hogy bármilyen konverziót alkalmazol, a bithelyességet már nem tudod értelmezni.
Tehát ha valóban purista elveket vall valaki, akkor nem nyűl hozzá a forráshoz, kivéve ami feltétlenül szükséges. Vannak dolgok, amiket én nem számolnék bithelyesség-elrontónak, ezek közös tulajdonsága, hogy az eredeti bitfolyam bitre pontosan rvisszaállítható belőlük:
- FLAC-ból az "eredeti" PCM visszaállítása
- a DSD bitfolyam DoP transzportcsomagokba pakolása
- PCM bizfolyam S/PDIF vagy AEU/EBU transzportcsomagokba pakolása
- 16 bites PCM 24-bitessé konvertálása a DAC számára nyolc darab alacsony helyiértékű NULLA bit hozzáadásával
- HATÁRESET, de már NAGYON rezeg a léc: a mintavételezési frekvencia az eredeti egész számú többszörösére való konvertálása oly módon, hogy az eredeti minták közé interpolált mintákat szúrnak be (de az eredeti bitfolyam jól azonosíthatóan és visszaállíthatóan megmarad)
Minden egyéb, pl PVM-DSD konverzió vagy pl 44.0 - 96 KHz konverzió semmilyen módon nem számít az én felfogásomban bithelyesnek.

De azt hiszem ez kissé filozófiai kérdés is, és figyeld meg, hogy én nálad is tovább mentem eredetileg...

Fura dolog ez a "bithelyesség"! Ha szigorúan architektúrálisan nézzük, akkor arról beszélünk, hogy van egy digitális távközlési csatornánk, amelynek a végén a "Vevő" bitről-bitre pontosan helyesen helyre tudja állítani az "Adó" oldalán bekerült információt.
A kérdés, hogy az audio lejátszó rendszereink melyik pontjára mutatunk, hogy "Adó", és melyikre, hogy "Vevő".
Ha a "puritánságot" akarnánk kimaxolni, akkor az "Adónak" a zenei információ tárolását végző médiumból kiolvasó és továbbító elemet kellene tekinteni, "Vevőnek" pedig a chip belsejében, vagy diszkrét elemekből felépített digitális/analóg átalakítást fizikailag kivitelező áramkört tápláló puffer kimenetét.
Már a mostani filozófia is sántít a puritanizmus szemszögéből, mikor a "Vevőként" a DAC eszköz bemeneti portját azonosítjuk, és figyelmen kívül hagyjuk a belsejében végrehajtandó transzformációkat a bpplay által addig a pontig bithelyesen továbbított információn.
Azokat az átalakításokat, amelyeket adott esetben épp a bpplay előtt is kivitelezhetnénk, sokkal hatékonyabban, kevesebb káros környezetei hatással, így váltva ki a DAC-ban végrehajtandó transzformáció szükségességét, vagy legalábbis csökkentve annak negatív hatását.
Vegyük észre, hogy a "bithelyesség" pusztán nómenklatúra, mint fizikai alapelv a gyakorlatban korlátozott a kivitelezése! Ugyanakkor sokan a jóság biztosítékaként tekintenek rá.

Amitől egyébként tartok Feri kísérletével kapcsolatban az, hogy annak ellenére, hogy Ő rendkívül konzekvensen kommunikálja az egész kísérlet edukációs jellegét, elutasítja a feltétlen "jobb hangra" törekvést, ezt a hobbit mélyen átitatja a bizonyos technológiai megoldások köré épített "kultusz", és nem adok sok időt annak, hogy megjelenjenek a "megtért" hívők, akik a bpplay puritanizmusában a tökéletesség biztosítékát, vagy legalábbis a jobb ígéretét látják, és az "audiofil" közösségen belül egyfajta "titkos tippként" fog terjedni, anélkül, hogy a megfelelő kontextusban kezelnék.
Ami az én olvasatomban az, hogy a puritanizmus az információ digitális formában történő tárolása, továbbítása, feldolgozása, és végül konverziója szempontjából óhatatlanul kompromisszumokkal jár. Ennek a folyamatnak és rendszernek egy bizonyos szakaszára készített Feri egy remek kis eszközt, amellyel a hatások tetten érhetők, de attól, hogy ezen a szakaszon a puritanizmusra törekedünk, a teljes kép még sokkal árnyaltabb lehet, és az eredmény sem feltétlenül javulás.
De lehet, hogy csak kiábrándult vagyok már, és tévedek.

[Aszpirin]

Valójában amit javasoltam az, hogy a bpplay tekintetében a "forrás" ne korlátozódjék az adathordozón/tárolón levő bitsorozat tökéletes másolatára, lehessen a forrás már transzformált jelsorozat is.
A Feri logikájának a lényege, hogy az adatforrás információ tartalma módosulatlanul juthasson el a DAC-hoz, és ez nem sérülne, csak a "forrás" definíciója bővül.
Így azok, akik a DAC-juk hangjához ilyen előfeldolgozást követően szoktak hozzá, mert eddig így tetszett, mint nekem a Laiv, a példának okáért, kipróbálhatják a bpplayt anélkül, hogy a szeretett minőségről le kellene mondaniuk, és a megszokott hangzáshoz viszonyítva vethetnék össze az alternatív útvonalak kínálta előnyöket/hátrányokat.
Persze elméletileg megoldható a kérdés az állomány előzetes offline átkódolásával is, de a HQPlayer nem támogatja, ha jól tudom.
Elnézést, ha túlfeszítettem a húrt!

Én ezt értem, de ez ettől még pontosan beleillik abba, amit írtam. Ha nem megfelelő a leátszási lánc további eleme - és akkor tegyük hozzá: ahhoz, amit kap a stúdióból - akkor a lejátszó általi konvertálgatás még férjen bele a bithelyességbe. A probléma ezzel épp csak az, hogy bármilyen konverziót alkalmazol, a bithelyességet már nem tudod értelmezni.
Tehát ha valóban purista elveket vall valaki, akkor nem nyűl hozzá a forráshoz, kivéve ami feltétlenül szükséges. Vannak dolgok, amiket én nem számolnék bithelyesség-elrontónak, ezek közös tulajdonsága, hogy az eredeti bitfolyam bitre pontosan rvisszaállítható belőlük:
- FLAC-ból az "eredeti" PCM visszaállítása
- a DSD bitfolyam DoP transzportcsomagokba pakolása
- PCM bizfolyam S/PDIF vagy AEU/EBU transzportcsomagokba pakolása
- 16 bites PCM 24-bitessé konvertálása a DAC számára nyolc darab alacsony helyiértékű NULLA bit hozzáadásával
- HATÁRESET, de már NAGYON rezeg a léc: a mintavételezési frekvencia az eredeti egész számú többszörösére való konvertálása oly módon, hogy az eredeti minták közé interpolált mintákat szúrnak be (de az eredeti bitfolyam jól azonosíthatóan és visszaállíthatóan megmarad)
Minden egyéb, pl PVM-DSD konverzió vagy pl 44.0 - 96 KHz konverzió semmilyen módon nem számít az én felfogásomban bithelyesnek.

De azt hiszem ez kissé filozófiai kérdés is, és figyeld meg, hogy én nálad is tovább mentem eredetileg...

[kaef2]

Valójában amit javasoltam az, hogy a bpplay tekintetében a "forrás" ne korlátozódjék az adathordozón/tárolón levő bitsorozat tökéletes másolatára, lehessen a forrás már transzformált jelsorozat is.
A Feri logikájának a lényege, hogy az adatforrás információ tartalma módosulatlanul juthasson el a DAC-hoz, és ez nem sérülne, csak a "forrás" definíciója bővül.
Így azok, akik a DAC-juk hangjához ilyen előfeldolgozást követően szoktak hozzá, mert eddig így tetszett, mint nekem a Laiv, a példának okáért, kipróbálhatják a bpplayt anélkül, hogy a szeretett minőségről le kellene mondaniuk, és a megszokott hangzáshoz viszonyítva vethetnék össze az alternatív útvonalak kínálta előnyöket/hátrányokat.
Persze elméletileg megoldható a kérdés az állomány előzetes offline átkódolásával is, de a HQPlayer nem támogatja, ha jól tudom.
Elnézést, ha túlfeszítettem a húrt!

Amikor kész a bpplay linuxos verziója, akkor lehet, hogy nekiállok egy offline konvertert csinálni. Pont azért, hogy a konverzió offline, a lehető legjobb minőségben történjen és segítse a "bithelyes" lejátszást. Ha valakinek fontos a DAC-hoz igazítás.

[juliush]

Valójában amit javasoltam az, hogy a bpplay tekintetében a "forrás" ne korlátozódjék az adathordozón/tárolón levő bitsorozat tökéletes másolatára, lehessen a forrás már transzformált jelsorozat is.
A Feri logikájának a lényege, hogy az adatforrás információ tartalma módosulatlanul juthasson el a DAC-hoz, és ez nem sérülne, csak a "forrás" definíciója bővül.
Így azok, akik a DAC-juk hangjához ilyen előfeldolgozást követően szoktak hozzá, mert eddig így tetszett, mint nekem a Laiv, a példának okáért, kipróbálhatják a bpplayt anélkül, hogy a szeretett minőségről le kellene mondaniuk, és a megszokott hangzáshoz viszonyítva vethetnék össze az alternatív útvonalak kínálta előnyöket/hátrányokat.
Persze elméletileg megoldható a kérdés az állomány előzetes offline átkódolásával is, de a HQPlayer nem támogatja, ha jól tudom.
Elnézést, ha túlfeszítettem a húrt!

[kaef2]

egy picit hadd játsszam az ördög ügyvédjét!

Én meg hadd álljak valahol középen.

A klérdés számomra filozófiai is.
Ha ugyanis a lejátszási láncban mind felvételt, a lejátszó előtti, mind az azután következő elemeket ideálisnak tekintjük, akkor bizony Feri megközelítése az ideális, azaz ha egy lejátszó a _feltétlenül_ szükségesen kívül nem nyúl bele a bitfolyamba, és ezt amennyire a lehetőségei elérnek, nem is engedi meg. Mint egyfajta ideális kábel, aminek minden fizikai paramétere ideális.

Az más kérdés, hogy ha a lejátszó utáni rész teljesítményével nem vagyunk elégedettek - akkor a lejátszó szoftver épp egy megfelelő hely ezek többé-kevésbé korrektciójához. Így a lejátszó nem lesz ugyan "bitperfekt", de a végeredmény a hallgatónak tetszőbb, a lejátszólánc további elemeinek és akár felvétel vagy a lehallgatási helyszn hibáinak javítására is alkalmas lehet.

Ezért szoktam én le a teljesen bitperfekt lejátszásról, és ezért használok fejhallgatókhoz konvolúciót és crossfeedet (tudom, tudom, mindkettő vitatható, de hadd legyen meg számomra a szubjektív értékelés lehetősége, nekem így jobban tetszik és kész :) ), hangsugárzós lejátszáshoz pedig szobakorrekciót épp a lejátszóban.

De figyeld meg, hogy Feri lejátszóla a felvételben alkalmazott minimalista elvei következetes továbbvitele a lejátszásba. Így viszont sem az ő (bocs, az MRC) felvételein, sem az ő lejátszóján nem múlik, hogy azt halld, ami a helyszínen (avagy a stúdióban) elhangzott.

Ha a DAC-od ebben már nem partner, az nem az ő dolga :) Majd lehet, hogy kijön a tökéletes és minimalista DAC koncepciójával is, ami az egyébként nagyon koherens filozófiájába illik.

Köszönöm, hogy észrevetted, igen az MRC analógia fontos. Kb pont ezt szerettem volna szoftverben elérni, mint ahogy az MRC felvételek készülnek és működnek az otthoni lejátszás során.

[kaef2]

Tényleg nem alábecsülve Feri nagyszerű munkáját, a létrehozott termék edukációs és demonstrációs potenciálját, de különösen a fejlesztés mentén született dokumentáció hasznosságát,

egy picit hadd játsszam az ördög ügyvédjét!

Az én tapasztalatom számos különböző architektúrájú DAC-kal az, hogy igen gyakran profitálnak az egyes átalakítók abból, ha nem az eredeti forrásból származó, bithelyes információval tápláljuk, hanem már előzetesen valamilyen transzformációnak vetjük alá a DAC eszköz előtt.

Nagyon gyakori, hogy a DAC mélyén a fizikai átalakítást végző konkrét áramköri kialakítás, legyen szó chipekről, speciális áramkörökről, nem egyezik natív adatformátumában a forráséval, így a DAC-on belül vagy önálló FPGA áramkörben, vagy magán a DAC chipen kialakított jelfeldolgozással erre történik a saját belső formátumra történő konverzió.

Tehát engem igazán olyan működési mód érdekelne, amelyben a "bithelyes forrást" egy külső DSP, mondjuk HQPlayer outputja jelenti. Ezt a vonalat végig gondolva, lenne még egy előnye, a HQPlayer már Roon végpont is lenne egyben.
Viszont még tovább gondolva, az ideális a Feri programját futtató NAA lenne, a HQPlayer-t futtató gépről hajtva.
Így a lejátszó oldal továbbra is minimalizált az bpplay-t futtató NAA-ban, a HQPlayer meg adná a DSP-t, meg a Roon katalógus menedzsmentjét önálló fizikai eszközön.

Kösz a felvetést. Szó van erről is érintőlegesen a cikksorozat első részében. Kb 10 évnyi HQplayeres kísérletezés után nem tehettem meg, hogy nem hozom szóba.

Ne felejtsük el, hogy nem az volt a célok, hogy valami óriásölőviláglegjobbja alkalmazást csináljak. Persze nem baj, ha az lesz belőle.
A célom eredendően csak annyi volt, hogy a lejátszáskor tudjam, hogy mi történik és hogy a lehető legjoban elkerüljem a malackodást a bitekkel. Amellett, hogy megnézzem mire lehet jutni LLM-eket használva a kódolással és az ellenőrzéssel.

Aztán ebből a szándékból lett a DIY alkalmazás. A magam kíváncsiságára szabva. Mint anno a 45-ös triódás, SE, 1,5W-os dual monoblokk erősítőm, kb 30 éve.

[Aszpirin]

egy picit hadd játsszam az ördög ügyvédjét!

Én meg hadd álljak valahol középen.

A klérdés számomra filozófiai is.
Ha ugyanis a lejátszási láncban mind felvételt, a lejátszó előtti, mind az azután következő elemeket ideálisnak tekintjük, akkor bizony Feri megközelítése az ideális, azaz ha egy lejátszó a _feltétlenül_ szükségesen kívül nem nyúl bele a bitfolyamba, és ezt amennyire a lehetőségei elérnek, nem is engedi meg. Mint egyfajta ideális kábel, aminek minden fizikai paramétere ideális.

Az más kérdés, hogy ha a lejátszó utáni rész teljesítményével nem vagyunk elégedettek - akkor a lejátszó szoftver épp egy megfelelő hely ezek többé-kevésbé korrektciójához. Így a lejátszó nem lesz ugyan "bitperfekt", de a végeredmény a hallgatónak tetszőbb, a lejátszólánc további elemeinek és akár felvétel vagy a lehallgatási helyszn hibáinak javítására is alkalmas lehet.

Ezért szoktam én le a teljesen bitperfekt lejátszásról, és ezért használok fejhallgatókhoz konvolúciót és crossfeedet (tudom, tudom, mindkettő vitatható, de hadd legyen meg számomra a szubjektív értékelés lehetősége, nekem így jobban tetszik és kész :) ), hangsugárzós lejátszáshoz pedig szobakorrekciót épp a lejátszóban.

De figyeld meg, hogy Feri lejátszója a felvételben is alkalmazott minimalista elvei következetes továbbvitele a lejátszásba. Így viszont sem az ő (bocs, az MRC) felvételein, sem az ő lejátszóján nem múlik, hogy azt halld, ami a helyszínen (avagy a stúdióban) elhangzott - amennyire ezt az alkalmazott technika lehetővé teszi.

Ha a DAC-od ebben már nem partner, az nem az ő dolga :) Majd lehet, hogy kijön a tökéletes és minimalista DAC koncepciójával is, ami az egyébként nagyon koherens filozófiájába illik.

[kaef2]

Az Apple Music ha maxra van benne a hangerő állítva és maxon van az USB DAC felé is a hangerő, akkor habár átmegy a mixeren a hang, de nem fog beleavatkozni, azon túl, ahogy a pufferelést másképpen csinálja.

Ezt CSAk abban az esetben tudom elképzelni, ha a mixerre küldött PCM formátum alap-paraméterei (mintavételezési frekvencia, bitráta) pontosan ugyanaz, mint a mixer kimenetére beállított, ÉS semmiféle lehetséges input (pl. mikrofon, rendszerhangok, stb), dsem egyéb "hangmanipuláció" (ld normalizálás, hangerő-szabályozás, effektusok) nincs aktiválva. Vagy ebben is tévednék, és esetleg van mixer-bemenet, ami "kiemelt" abból a szempontból, hogy az ott érkező PCM stream parmétereire azonnal átállítja a kimenet paramétereit is?
Mert ha nem tévedek, ez azért egy elég durva megszorítéás. Állítgasd mindig a mixer kimenetét, valahányszor a forrás alap-paraméterei változnak, ez mennyire user friendly dolog?
A mixer nevéből is fakadó jellegéből adódóan ugynis adódik, hogy a kevert anyagnag kel legyen egyféle PCM-paraméterezése.
Ahányszor én próbáltam összehasonlítan bármivel az Apple Music-ot, a mixer rátelepedése a hangra sajnos eléggé hallható volt.
Természetesen tévedhetek, mert elég rég foglalkoztam már az Apple Nusic és rendszermixer kapcsolatával, őt magával a rendszermixerrel is, aóta sok víz lefolyt...

Természetesen minden úgy volt beállítva, hogy ez ideális legyen a belemalackodás elkerülésére.

[Aszpirin]

(hehe, megérkezett Linus Torvalds is )

[juliush]

Tényleg nem alábecsülve Feri nagyszerű munkáját, a létrehozott termék edukációs és demonstrációs potenciálját, de különösen a fejlesztés mentén született dokumentáció hasznosságát,

egy picit hadd játsszam az ördög ügyvédjét!

Az én tapasztalatom számos különböző architektúrájú DAC-kal az, hogy igen gyakran profitálnak az egyes átalakítók abból, ha nem az eredeti forrásból származó, bithelyes információval tápláljuk, hanem már előzetesen valamilyen transzformációnak vetjük alá a DAC eszköz előtt.

Nagyon gyakori, hogy a DAC mélyén a fizikai átalakítást végző konkrét áramköri kialakítás, legyen szó chipekről, speciális áramkörökről, nem egyezik natív adatformátumában a forráséval, így a DAC-on belül vagy önálló FPGA áramkörben, vagy magán a DAC chipen kialakított jelfeldolgozással erre történik a saját belső formátumra történő konverzió.

Ez több szempontból is rányomhatja a bélyegét a hangzásra:

• Egyrészt a belül (FPGA-ban, vagy a chipen) megvalósított DSP algoritmusok képességei adottak, és igen gyakran kompromisszumos minőséget képviselnek. Gyakori, hogy az architektúra/algoritmus valamelyik formátummal jobban működik, jobban szól. Lásd Sabre chipes DAC-ok gyakran jobban szólnak előzetesen DSD-re konvertált anyaggal!

• A belső aritmetikai számítások pontosan ugyanúgy zajforrásként viselkedhetnek nem megfelelő tervezés, kialakítás esetén, mint a Feri által leírt folyamatok a számítógépben, csak az azonos házban, a fizikai közelség miatt még inkább.

Példa van persze arra is, hogy a DAC gyártói tényleg elvégezték a házi feladatukat mind a hardver, mind a szoftver terén, és jobb rájuk bízni a bithelyes adatfolyam feldolgozását, konvertálását, ilyen az Exogal Comet, és a Resonessence Labs Invicta az általam használtak közül.
De ellenkező példaként itt van a Laiv Crescendo Verse, ami nem rendelkezik rekonstrukciós szűrővel, így számomra megfelelő hangzást csak a "tükörképeket" 8 - 16-szoros túlmintavételezéssel a hallható tartománytól jó messze feltolva produkál, csak sajnos a saját belső szűrői nem ütik meg az általam elvárt szintet. Így végül NOS módban használom, az audio PC-men futó HQPlayer remek szűrőivel végeztetve el a "zajos" munkát.

Tehát engem igazán olyan működési mód érdekelne, amelyben a "bithelyes forrást" egy külső DSP, mondjuk HQPlayer outputja jelenti. Ezt a vonalat végig gondolva, lenne még egy előnye, a HQPlayer már Roon végpont is lenne egyben.
Viszont még tovább gondolva, az ideális a Feri programját futtató NAA lenne, a HQPlayer-t futtató gépről hajtva.
Így a lejátszó oldal továbbra is minimalizált az bpplay-t futtató NAA-ban, a HQPlayer meg adná a DSP-t, meg a Roon katalógus menedzsmentjét önálló fizikai eszközön.

[Aszpirin]

Természetesen csináltam összehasonlítást Apple Music-kal, Roon-nal, Audirvana Studióval, HQplayerrel, Veravox-szal,

És a többivel is annyira nyilvánvaló volt a különbség? Ténylkeg érdekel.

[Aszpirin]

Az Apple Music ha maxra van benne a hangerő állítva és maxon van az USB DAC felé is a hangerő, akkor habár átmegy a mixeren a hang, de nem fog beleavatkozni, azon túl, ahogy a pufferelést másképpen csinálja.

Ezt CSAk abban az esetben tudom elképzelni, ha a mixerre küldött PCM formátum alap-paraméterei (mintavételezési frekvencia, bitráta) pontosan ugyanaz, mint a mixer kimenetére beállított, ÉS semmiféle lehetséges input (pl. mikrofon, rendszerhangok, stb), dsem egyéb "hangmanipuláció" (ld normalizálás, hangerő-szabályozás, effektusok) nincs aktiválva. Vagy ebben is tévednék, és esetleg van mixer-bemenet, ami "kiemelt" abból a szempontból, hogy az ott érkező PCM stream parmétereire azonnal átállítja a kimenet paramétereit is?
Mert ha nem tévedek, ez azért egy elég durva megszorítéás. Állítgasd mindig a mixer kimenetét, valahányszor a forrás alap-paraméterei változnak, ez mennyire user friendly dolog?
A mixer nevéből is fakadó jellegéből adódóan ugynis adódik, hogy a kevert anyagnag kel legyen egyféle PCM-paraméterezése.
Ahányszor én próbáltam összehasonlítan bármivel az Apple Music-ot, a mixer rátelepedése a hangra sajnos eléggé hallható volt.
Természetesen tévedhetek, mert elég rég foglalkoztam már az Apple Nusic és rendszermixer kapcsolatával, őt magával a rendszermixerrel is, aóta sok víz lefolyt...

[kaef2]

A vicces az, hogy bluetooth-on is jól hallható hatása van, az Apple Music-hoz képest a bpplay - nek

Feri, azt hiszem mindketten tudjuk, hogy az Apple Music-kal való összehasonlítás ezen eredménye várható volt. Elég egyértelmű onnantól kezdbve, hogy az Apple Music tudomásom szerint még mindig használjja a rendszermixert, vagyis nem hog mode-ban dolgozik.

Az érdekes összehasonlítás egy Audirvanával lenne, amelyben bazinagy memóriapuffer van beállítva (pl. 8GB), mert akkor az Audirvana a DAC-ra küldendő nyers adatokat a memóriában készíti elő, teljes egészében a lejátszás elején, és ha nem nyúlunk a hangerőszabályozóhoz és hagyjuk az integeer módot is, akkor sejtésem szerint kb az fog történni, amit a Te lejátszód is csinál - és ez rögtön magyarázza, hogy miért imádják olyan sokan az Audirvana hangját.

(H lesz egy kis időm - vagyis a hétvégén - alighanem el is végzem ezt az összehasonlítást, mert Audirvana 3.5-m még mindig van....)

Természetesen csináltam összehasonlítást Apple Music-kal, Roon-nal, Audirvana Studióval, HQplayerrel, Veravox-szal, Fidelizer-rel és J Riverrel is a bpplay relációban. Az Apple Music ha maxra van benne a hangerő állítva és maxon van az USB DAC felé is a hangerő, akkor habár átmegy a mixeren a hang, de nem fog beleavatkozni, azon túl, ahogy a pufferelést másképpen csinálja. Persze a mintavétel váltást ekkor is kézzel kell megcsinálni, még mindig nincs beépített automatizmus erre (a MacOS 27 Developer betában sem) szemben az iOS-szel.

A régi Audirvana esetében nem elég a memóriába töltés önmagában, a kiolvasást vezérlő IOproc hívás prioritása is számít, azt meg tudomásom szerint nem úgy kezeli, mint a Bpplay.

[Aszpirin]

A vicces az, hogy bluetooth-on is jól hallható hatása van, az Apple Music-hoz képest a bpplay - nek

Feri, azt hiszem mindketten tudjuk, hogy az Apple Music-kal való összehasonlítás ezen eredménye várható volt. Elég egyértelmű onnantól kezdbve, hogy az Apple Music tudomásom szerint még mindig használjja a rendszermixert, vagyis nem hog mode-ban dolgozik.

Az érdekes összehasonlítás egy Audirvanával lenne, amelyben bazinagy memóriapuffer van beállítva (pl. 8GB), mert akkor az Audirvana a DAC-ra küldendő nyers adatokat a memóriában készíti elő, teljes egészében a lejátszás elején, és ha nem nyúlunk a hangerőszabályozóhoz és hagyjuk az integeer módot is, akkor sejtésem szerint kb az fog történni, amit a Te lejátszód is csinál - és ez rögtön magyarázza, hogy miért imádják olyan sokan az Audirvana hangját.

(H lesz egy kis időm - vagyis a hétvégén - alighanem el is végzem ezt az összehasonlítást, mert Audirvana 3.5-m még mindig van....)

[Aszpirin]

Lehet erdemes lenne neki nyitni egy kulon topikot, tapasztalatokkal es frissitesekkel bar nem tudom mi a vegso celod vele. :) Esetleg Roon ala be aplikalhoto-e osszevetve pl a HQPlayer-al, stb.

Hadd válaszoljak erre Feri helyett, aztán majd kijavít ha nincs igazam.

Bár pl. az Audirvana, különösen a 3.5, ugyanezekre az elvekre épül (miközben már benne van egy halom komplikáció i), és a Roon lokális lejátszás része is (roon bridge és/vagy lejátszás direktben USB DAC-ra), ha nem DSP-zel, de ezek közül egyik sem nyílt forráskódú ingyenes, és van még valami: a dolog oktatási oldala... Amit Feri bemutat, az egy jó értelemben vett totál minimalista megvalósítása a bitperfekt lejátszásnak, semmi fölösleges sallang, semmi zavaró tényező, legalábbis amennyire ez a lejátszó szoftveren múlhat.
Annak, hogy ezt "beépíteni" a Roon-ba, ebben a formában nem értelmezhető megközelítés, mert pont a lényegét, a lejátszás minimalizmusát veszítenéd el vele.

[kaef2]

Bekerült egy jelentős és fontos kiegészítés a cikkbe, így utólag, a Linux verzió fejlesztése során begyűjtött tapasztalat alapján.

A tárgya az a szakasza a feldolgozási útvonalnak, ami a RAM-tól az USB DAC puffereiig tart.

A macOS-es bpplay már most is jelentősen csökkenti a szoftveres zajt azzal, hogy mindent RAM-ba tölt és minimális műveletet végez a lejátszás alatt. Azonban a Core Audio HAL még mindig egy ún vastag absztrakciós réteg, amely saját szálakon és belső puffereken keresztül kommunikál a hardverrel.

A Linuxos ALSA Direct verzióval lehetőség nyílik arra, hogy ezt a réteget tovább vékonyítsuk. Kevesebb memóriamásolás, közvetlenebb hozzáférés a DMA pufferhez, és nagyobb kontroll az időzítés felett — mindez potenciálisan még alacsonyabb és kiszámíthatóbb rendszeraktivitást eredményezhet a lejátszás során.

Ez az a pont, ahol a SCHED_FIFO és a valós idejű Linux kernel (PREEMPT_RT) már nem csak elméleti lehetőség, hanem konkrét előnyt jelenthet. Vagyis van rá esély, hogy a Linux verzió akár egy picit “jobban” is szólhat (bármit is jelentsen a jobb ebben az esetben). Esélyünk lehet arra, hogy azt halljuk, ami a file-okban mentésre került, minimalizálva az esetlegesen fellépő zajok, plusz jitter potenciális hatásait a lejátszásra.

Ezen az íráson úgy jó tíz éve gondolkodom.

A számítógépes zenehallgatás során a gépben zajló folyamatokról szól, specifikusan a MacOS ún Core Audio alrendszerét górcső alá téve. A bpplay core alkalmazás AI segítséggel történő fejlesztésével, azt hiszem feltaláltam a Csináld Magad (DIY) audiophile szoftvert. Kicsivel több, mint 40 éve, még egyetemi éveim alatt építettem az első csöves erősítőmet (Vass-Andrási György (RIP) segítségével). Úgy 30 éve az első drága alkatrészekből, japán és amerikai szakirodalom segítségével összerakott SE 45 triódás monoblokkokat (1,5W volt a teljesítményük ), és nagyjából ez időben kezdtem el kísérletezni különböző anyagú és szerkezetű kábelek audio célú felhasználásával.

Vagyis van valami kapcsolatom a DIY világgal, de azt még pár hónappal ezelőtt sem gondoltam volna, hogy egyszer csak szoftvert csinálok DIY módszerrel.

Az alábbi írás a tegnap közzétett bpplay alkalmazás létrehozásáról szóló sorozat második része. Nehéz és hosszú olvasmány lesz. Talán egyszer majd csinálok belőle egy sokkal rövidebbet, olvasmányosabbat is, de nem biztos.

Sok türelmet kívánok az olvasásához.

https://medium.com/@mediaengineering/bp ... 2cf398e7dd

[kaef2]

Szuper!
Lehetséges, hogy a Linux verzió Raspberry Pi-n is fut?
Hálás köszönet a fáradozásodért!
D'

Lehetséges.
Előbb az inteles verzió lesz készen (talán már a jövő héten) és aztán jön az Arm. Nagyon egyszerű oka van a sorrendnek: az intelest tudom jelenleg kipróbálni, Raspberry most nincs otthon. de majd szerzek addiga egyet.
A MacOS verzióból a proof of concept verziót már kipróbálták páran. Most elkészült az 1.1, a legnagyobb változás, hogy úgy van megcsinálva, hogy könnyen forduljon Linuxra, de persze van benne pár egyéb változás is, például a 32 bites integer PCM mintavételezés kapcsán. Mondjuk valószínűleg nem sokan hallgatnak 32 bites integer file-okat otthon, de ha mégis, akkor jól fog működni. A vicces az, hogy bluetooth-on is jól hallható hatása van, az Apple Music-hoz képest a bpplay - nek és úgy tűnik működik a pro audióban elterjedt Ravenna protokollal, etherneten csatlakozó eszközökkel is, mint a Merging Ravenna.

Lehet erdemes lenne neki nyitni egy kulon topikot, tapasztalatokkal es frissitesekkel bar nem tudom mi a vegso celod vele. :) Esetleg Roon ala be aplikalhoto-e osszevetve pl a HQPlayer-al, stb.

Az a célom, hogy legyen egy referencia lejátszó eszköz, ami esetében tökéletesen lehet tudni mi történik a lejátszás során. A GitHub-on publikálva lesz a forrás kód, tök ingyenesen lehet majd használni és felhasználni.

Hajnalban elkészült a v1.1 installer is.
A pár ember által már kipróbált v0.9-hez képest két változás van:
- olyan módon lett átírva a kód, hogy a bithelyességet és a teljes egészében memóriából történő lejátszást nem befolyásolva könnyebben lehessen létrehozni a Linux verziót,

illetve

- bekerült egy kiegészítés a 32 bit, integer file lejátszáshoz. Ami persze sokakat nem érdekel valószínűleg, nem nagyon vannak 32 bites integre file-ok kereskedelmi forgalomban legfeljebb csak produkció folyamatok során képződnek. A teljességhez fontosnak tartottam ezek kezeléséről is gondoskodni.

Elkészült felhasználói kézikönyv is, magyar mellett angolul is. Ha egy-két napot már teszteltem a v1.1-et, akkor lehet jelentkezni és szívesen elküldöm az érdeklődőknek.

A Linux verzió miatt bekerült egy hosszú kiegészítés a memóriakezelés és az USB eszközök pufferei működése kapcsán a cikksorozat második részébe. Érdemes emiatt esetleg újraolvasni a cikket. Fontos kiegészítés a folyamatok megértéséhez.

https://mediaengineering.medium.com/bpp ... 2cf398e7dd

A külön topik nem rossz ötlet, már csak azért sem, mert készül a Linux verzió is, és az ugye itt hülyén nézne ki.

[tottyi]

Köszönöm az elismerő szavakat. Nem véletlenül írtam, hogy 10 éve érlelődik bennem.

A user manual utolsó, 18-ik oldalán ott van hogy:



Vagyis nyílt forráskóddal szabadon (ingyen) elérhetővé teszem majd további tesztelés után. A forráskóddal együtt.
A Linux verziót is.

Szuper!
Lehetséges, hogy a Linux verzió Raspberry Pi-n is fut?
Hálás köszönet a fáradozásodért!
D'

Lehetséges.
Előbb az inteles verzió lesz készen (talán már a jövő héten) és aztán jön az Arm. Nagyon egyszerű oka van a sorrendnek: az intelest tudom jelenleg kipróbálni, Raspberry most nincs otthon. de majd szerzek addiga egyet.
A MacOS verzióból a proof of concept verziót már kipróbálták páran. Most elkészült az 1.1, a legnagyobb változás, hogy úgy van megcsinálva, hogy könnyen forduljon Linuxra, de persze van benne pár egyéb változás is, például a 32 bites integer PCM mintavételezés kapcsán. Mondjuk valószínűleg nem sokan hallgatnak 32 bites integer file-okat otthon, de ha mégis, akkor jól fog működni. A vicces az, hogy bluetooth-on is jól hallható hatása van, az Apple Music-hoz képest a bpplay - nek és úgy tűnik működik a pro audióban elterjedt Ravenna protokollal, etherneten csatlakozó eszközökkel is, mint a Merging Ravenna.

Lehet erdemes lenne neki nyitni egy kulon topikot, tapasztalatokkal es frissitesekkel bar nem tudom mi a vegso celod vele. :) Esetleg Roon ala be aplikalhoto-e osszevetve pl a HQPlayer-al, stb.

[kaef2]

Köszönöm az elismerő szavakat. Nem véletlenül írtam, hogy 10 éve érlelődik bennem.

A user manual utolsó, 18-ik oldalán ott van hogy:

Ez a szoftver szabad szoftver; terjeszthető és/vagy módosítható a Free Software Foundation által
kiadott GNU Általános Nyilvános Licenc (GNU General Public License v3, GPLv3) feltételei alapján.

Vagyis nyílt forráskóddal szabadon (ingyen) elérhetővé teszem majd további tesztelés után. A forráskóddal együtt.
A Linux verziót is.

Szuper!
Lehetséges, hogy a Linux verzió Raspberry Pi-n is fut?
Hálás köszönet a fáradozásodért!
D'

Lehetséges.
Előbb az inteles verzió lesz készen (talán már a jövő héten) és aztán jön az Arm. Nagyon egyszerű oka van a sorrendnek: az intelest tudom jelenleg kipróbálni, Raspberry most nincs otthon. de majd szerzek addiga egyet.
A MacOS verzióból a proof of concept verziót már kipróbálták páran. Most elkészült az 1.1, a legnagyobb változás, hogy úgy van megcsinálva, hogy könnyen forduljon Linuxra, de persze van benne pár egyéb változás is, például a 32 bites integer PCM mintavételezés kapcsán. Mondjuk valószínűleg nem sokan hallgatnak 32 bites integer file-okat otthon, de ha mégis, akkor jól fog működni. A vicces az, hogy bluetooth-on is jól hallható hatása van, az Apple Music-hoz képest a bpplay - nek és úgy tűnik működik a pro audióban elterjedt Ravenna protokollal, etherneten csatlakozó eszközökkel is, mint a Merging Ravenna.

[Deenoo]

Köszönöm az elismerő szavakat. Nem véletlenül írtam, hogy 10 éve érlelődik bennem.

A user manual utolsó, 18-ik oldalán ott van hogy:

Ez a szoftver szabad szoftver; terjeszthető és/vagy módosítható a Free Software Foundation által
kiadott GNU Általános Nyilvános Licenc (GNU General Public License v3, GPLv3) feltételei alapján.

Vagyis nyílt forráskóddal szabadon (ingyen) elérhetővé teszem majd további tesztelés után. A forráskóddal együtt.
A Linux verziót is.

Szuper!
Lehetséges, hogy a Linux verzió Raspberry Pi-n is fut?
Hálás köszönet a fáradozásodért!
D'

[hifis]

Ezen az íráson úgy jó tíz éve gondolkodom.
...
https://medium.com/@mediaengineering/bp ... 2cf398e7dd

Hiánypótló ez az írás, mondhatni hasonlóképp tananyag. A számítógépes audiofil zenelejátszás alapjai.

Aki teheti, vagyis van Apple számítógépe, ne csak olvassa, próbálja is ki! Nekem Feri elküldte a programot, és komoly meglepetést okozott a hangjával. Lehet, hogy tényleg referencia. Először egy Ifi Micro usb dac-ot, utána pedig a Merging Technologies Anubis AD/DA audio interfészt kötöttem a MacBook Pro-ra. Az egyik az elterjedt usb-n, de a másik a kuriózumnak számító ethernet kábelen (Ravenna protokoll) fogadja a zenét. A program simán, csont nélkül kiszolgálta mindkettőt. Érdekességképpen berakom az Audio Midi Setup képernyőképét, ahol az a különleges, hogy az audio kimenetet jelző kis hangszóró a MacBook speakers-nél van, de nem ott megy ki a hang, hanem a program által "lakattal" lefoglalt Ravenna, vagyis az Anubis dac felé. Ilyet semmilyen más lejátszónál nem láttam.

[kaef2]

Ezen az íráson úgy jó tíz éve gondolkodom.
...
https://medium.com/@mediaengineering/bp ... 2cf398e7dd

Hiánypótló ez az írás, mondhatni hasonlóképp tananyag. A számítógépes audiofil zenelejátszás alapjai.

Köszönöm az elismerő szavakat. Nem véletlenül írtam, hogy 10 éve érlelődik bennem.

A user manual utolsó, 18-ik oldalán ott van hogy:

Ez a szoftver szabad szoftver; terjeszthető és/vagy módosítható a Free Software Foundation által
kiadott GNU Általános Nyilvános Licenc (GNU General Public License v3, GPLv3) feltételei alapján.

Vagyis nyílt forráskóddal szabadon (ingyen) elérhetővé teszem majd további tesztelés után. A forráskóddal együtt.
A Linux verziót is.

[Aszpirin]

Ezen az íráson úgy jó tíz éve gondolkodom.
...
https://medium.com/@mediaengineering/bp ... 2cf398e7dd

Ahogy olvastam, Andy Tannenbaum jutott eszembe, aki egy egész könyvet írt arról hogy egy tökéletes operációs rendszer kernel milyen kihívásokkal szembesül, és ezeket hiogyan lehet feloldani.... és a könyv mellékleteként az ezen elvek alapján megírt operációs rendszer, a MINIX forráskódját is közölte. (a MINIX kódja sok fejlesztőt inspirált, talán a legfontosabb ezek közül Linus Torvalds, aki a Linux kapcsán egy igen érdekes és nagyon konstruktív elvi intellektuális vitát folytatott le Andy Tannenbaum-mal. Ha párhuzamba állítjuk ezt a Te írásoddal, akkor egy ilyen szakmai-filozófiai vita alapja lehetne, hogy kell-e törekedni a bitperfektségre )

Hiánypótló ez az írás, mondhatni hasonlóképp tananyag. A számítógépes audiofil zenelejátszás alapjai.
Kár, hogy ezen a fórumon az ilyen értékek (mert EZ az értékteremtés, a javából) már alig érdekelnek egy-két embert az örökzöld kábel-marakodás meg fotelokoskodás mellett, az értékteremtés teljesen háttérbe szorult, és ez azon is látszik, hogy milyen kevés reakció érkezett erre és az előző bejegyzésedre is.

Gratulálok a kitartásodért, és a valódi értékteremtésért, amit még ide behozol nekünk.

Zseniális írás, várom a harmadik részt.

[kaef2]

Ezen az íráson úgy jó tíz éve gondolkodom.

A számítógépes zenehallgatás során a gépben zajló folyamatokról szól, specifikusan a MacOS ún Core Audio alrendszerét górcső alá téve. A bpplay core alkalmazás AI segítséggel történő fejlesztésével, azt hiszem feltaláltam a Csináld Magad (DIY) audiophile szoftvert. Kicsivel több, mint 40 éve, még egyetemi éveim alatt építettem az első csöves erősítőmet (Vass-Andrási György (RIP) segítségével). Úgy 30 éve az első drága alkatrészekből, japán és amerikai szakirodalom segítségével összerakott SE 45 triódás monoblokkokat (1,5W volt a teljesítményük ), és nagyjából ez időben kezdtem el kísérletezni különböző anyagú és szerkezetű kábelek audio célú felhasználásával.

Vagyis van valami kapcsolatom a DIY világgal, de azt még pár hónappal ezelőtt sem gondoltam volna, hogy egyszer csak szoftvert csinálok DIY módszerrel.

Az alábbi írás a tegnap közzétett bpplay alkalmazás létrehozásáról szóló sorozat második része. Nehéz és hosszú olvasmány lesz. Talán egyszer majd csinálok belőle egy sokkal rövidebbet, olvasmányosabbat is, de nem biztos.

Sok türelmet kívánok az olvasásához.

https://medium.com/@mediaengineering/bp ... 2cf398e7dd