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

[Aszpirin]

Ha mar igy belelendultel akkor mar egy operacios rendszert ami semmi mast nem tud csak listazza a hdd-en vagy ssd-en a zeneket es lejatsza vagy arreb ugrasztja a szamokat. :)

Ne tudjon semmi mást? Billentyűzetet/egeret kezelni se? Monitort kezelni se? Na jó, csak viccelek. Zenére optimalizált OS van már dögivel. Igz, nem annyira minimalista, mint amit Te szeretnél, végülis igaz, kva jó lehet mondjuk 10ezer szám között egyesével ugrasztással keresgélni

[tottyi]

Ha mar igy belelendultel akkor mar egy operacios rendszert ami semmi mast nem tud csak listazza a hdd-en vagy ssd-en a zeneket es lejatsza vagy arreb ugrasztja a szamokat. :)

[Aszpirin]

Ez a konverter tervezett funkcionalitása:

Jó kis projekt lesz ez is És időigényes, még végigpromptolni ezt mind megfelelőképpen, meg mindent is letesztelni, hát ezzeél lesz munka....

Vicces lesz minden funkcióra CLI parancsot és megfelelő paraméterezést összehozni. Kíváncsi vagyok, ebben majd hogy teljesít az AI Ha jól értem, GUI-t nem is számsz ennek (?)
Javaslom egy leírü formátum kiagyalását is, amellyel szépen le lehet írni mondjuk Yaml-ben, hogy milyen transzformációkat/műveleteket akar a user a bemeneti fájl(ok)on végrehajtani kötegelve, és CLI-ban ezt rá lehessen engedni több fájlra, akár wildcardos pattern alapján, akár egy egész könyvtrtartalomra Csak hogy izzadjon a hardver. (itt ényleg értelmet fog nyerni a "számítógép" kifejezés )

[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.

Ez a konverter tervezett funkcionalitása:

Szűrőtervezés
- Ablakozott FIR szűrők:
- Kaiser ablak (paraméterezhető β, >200 dB csillapítás)
- Dolph‑Chebyshev ablak (egyenletes zárósávi csillapítás)
- Ultraszférikus ablak (extrém éles átmenet)

Fázisvariánsok:
- Lineáris fázis (szimmetrikus FIR)
- Minimum fázis (apodizáló, cepstrum módszerrel)
- Köztes fázis (opcionális, pl. 50% lineáris)
- Szűrőhossz: tetszőleges, akár több tízmillió együttható

Többfokozatú (kaszkád) tervezés: automatikus felbontás interpolációs/decimáló lépcsőkre

Polyphase FIR átmintavételező motor
- Tetszőleges racionális arány (L/M) támogatása
- Extrém pontosság: duplapontos (64-bit) számítás, akár 80/128 bites kiterjesztés
- Időkésleltetés precíz kezelése (lineáris fázis esetén automatikus kompenzáció)
- Minimál fázisú szűrők támogatása (késleltetés nélküli mód)
- FFT alapú konvolúció opció (ultra hosszú szűrőkhöz, overlap‑save)
- Többszálúsításra előkészítve (OpenMP)

Dither és zajformálás
- TPDF dither (2 LSB csúcs-csúcs)

Zajformálók:
- Shibata (SoX stílusú)
- Lipshitz
- Egyedi (custom) tetszőleges együtthatókkal (akár 9. rendig)
- Pszichoakusztikus (Fletcher‑Munson) zajformálás

Bitmélységek: 16, 24 bit (tovább bővíthető)

In‑place feldolgozás, duplapontos kimenet

Szigma‑delta modulátor PCM→DSD
- Rendek: 5, 7, 9, 11, 13, 15 (páratlan)
- Struktúra: CRFB (Cascaded Resonator Feedback) integrátorokkal
- Klippelésvédelem a stabilitásért

Kimenet: DSD bitfolyam (LSB first csomagolás)
Felhasználás: akár 64×, 128×, 256× DSD előállítása

DSD→PCM visszaalakítás
- Polyphase decimálás extrém éles szűrőkkel
- DSD bitfolyam → multi‑bit átalakítás mozgóátlag előszűréssel

Fájlformátumok
Bemenet: WAV, FLAC (16/24/32 bit, float)
Kimenet: WAV, FLAC, DSF (DSD fájl)

DSF író/olvasó Pythonban, teljes fejléc kezeléssel

Mérések és validáció (AES17 / IEC 61606)
- THD+N (szinusz sweep, A-súlyozással, sávszűréssel)
- IMD SMPTE (60 Hz + 7 kHz)
- IMD CCIF (19 kHz + 20 kHz)
- Zajszint (A-súlyozott, dBFS)
- Frekvenciaválasz (sweep alapú, amplitúdó és fázis)
- Impulzusválasz (pre‑ringing, post‑ringing analízis)
- Aliasing / imaging spektrumanalízis (különbségi jel spektruma)
- Szűrő együtthatók validációja (passband ripple, stopband attenuation)
- Bit‑pontosság ellenőrzése
- Kereszt-wavelet teljesítményspektrum
- Wavelet koherencia és fáziseltérés

Eredeti vs. konvertált fájlok közvetlen összehasonlítása:
- RMS hiba (abszolút és relatív)
- Csúcs hiba
- Korrelációs együttható
- Frekvenciamenet‑eltérés
- Különbségi jel hullámformája
- Spektrum overlay

Jelentéskészítés
Automatikus PDF riport (matplotlib + reportlab)

Tartalmazhatja:
- THD+N sweep grafikon
- Frekvenciamenet
- Impulzus viselkedés
- Wavelet skalogramok és koherencia
- Összehasonlító metrikák táblázata
- Batch tesztelés több fájlra, CSV eredmény export

Parancssori és integrációs lehetőségek
- CLI vezérlés Pythonból (hqconv.py)
- Szűrőtervező CLI (filter_design.py)
- Összehasonlító CLI (compare_cli.py)
- Mérő CLI (measure_cli.py)
- C könyvtár (libhqconv.so) ctypes interfésszel, bármilyen Python/C projektbe ágyazható

Extrém minőségű opciók (hosszú render idő!)
- Kaszkád többfokozatú átalakítás (akár 100 MHz köztes frekvencia)
- FFT alapú nulla‑fázisú szűrés (forward‑backward)
- Extrém lebegőpontos számítások (long double, __float128)
- Modulátorok magasabb rendjei (stabilitás optimalizálással)
- Egyedi zajformáló profilok (Fletcher‑Munson görbe)

[wittao]

Magam reszerol a Bughead ota drukkolok ezeknek a kis programoknak, nagyon udvozlom a kezdemenyezest.
Mindemellett h. joideje a JRIVER Kernel Streaming vonalrol az Audirvana ASIO vonalat preferalom Win kornyezetben (ez utobbi is megerne egy miset).
Majd mindenkeppen szeretnem kiprobalni a Feri uj fejleszteset, mert hentereg itt egy-ket mac, amik szinte visitanak azert hogy hasznossa tegyek magukat. Ugyanakkor szoftver ide vagy oda, sajnos a mac-es alap hardverek azert nem a mi audiofulek szamara keszultek.
Linuxos vilagban valami hasonlot csinalt par eve Sukkosd Gabi, egy egyszeru Linuxos Lenovo notibol igencsak komoly hangot facsart ki, hasonlo gondolatok menten.

Valojaban itt is szerintem mar vannak ugymond “utak”, amiket a hifistak korbejartak es megtalaltak a jelenlegi hardveres kedvenceiket es az ahhoz passzolo szoftverkornyezetet. Van, aki a vilagurbe kilovi a felskalazast, kvantalasi zajcsokkentesben hisz es minden 1532PCM vagy 1024DSD fut nala. De minden rakfeneje a dac hardver (is), nem csupan a PC oldale. Elegge alaposan erdemes vegignezni egy dac belso architekturajat is, es utana mar jon a dac chip h. az mit muvel a mi himestojasokon finoman beadagolt bithelyes adatfolyamunkkal…

Emlekszem korabbi PCM1792 dac-chip egesz egyszeruen 24/96PCM-re volt optimalizalva, meg az eretneknek tuno 16/44.1-24/96 konverziot is erdemes volt megtenni, mert meg ugy is jobban szolt a hallgatok tobbsege szamara, mint a nativ bekuldott anyag (dac chip manualjaban fel is lehet fedezni ennek az okat).

Jelenleg amit mi epitettunk legutobbi dac-unk egy picit tradicionalisabb utat valosit meg, ami be megy az elejen, az jut be a dac chiphez is, semmifele clock es egxeb marhasagot nem rakunk defaultban bele. Persze az opciok ott vannak, sot a felhasznalonak meg valamilyen szintu beleszolasa is van, filterekkel, upsamplinggal ha nagyon szeretne, csinalja.

Lejatszasi oldalon most eppen rpi-zunk a fo x86 csapasirany mellett, es az ALSA-nal is vannak erdekessegek, amikre Feri is kitert. Ott is vannak rejtett tartalekok, de az teny, h. a BSD alapokon nyugvo OS-el joval kisebb galibat okoznak, mint mondjuk egy Win10-11 megszeliditese lejatszasra.
Ugy erzem a Win12 ARM valtozata fog elhozni valamit a viszonylag kotott hardver miatt, ahol mar nekunk is tobb beleszolasunknlesz sajat alap hardver gyartasaval. Persze itt a Win csak egy opcio.
Amit Juliush emlitett NAA hazasitas egyebkent egy kivalo otlet azoknak, akik mar megszoktak a dac-juk altal veluk szemben tamasztott kovetelmenyek kiszolgalasat + szeretnek a lejatszasi oldalon is megtenni a szukseges lepeseket.

[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.