Parancssorból és külső függőség használatával megoldható, pár nap alatt. Benne van az implementációs tervemben egy saját ISO parser fejlesztése is, hogy ne legyen külső függőség, ez lehet egy - két hét. Utána megoldható a GUI-ban is egy almenü hozzá, hogy ne parancssorból kelljen megcsinálni.
, bekerült pár új funkció is az elmúlt két napban. 
A barátomat nem igazán érdekli az audio optimalizáció sajnos, már többször próbáltam rávenni. De azt megígérte, hogy amikor meglesz a Linux Bpplay verzió, megnézi majd a forrás kódot és ki is próbálja. Talán a jövő héten erre már lesz módja, ha minden jól megy. A jövő héten elérhetővé teszem majd a mostani MacOS verziót is, addig tesztelik nekem páran és persze én is.wittao írta: ↑2026.06.23., kedd 17:43Hatha lenne egy ilyen, audio specifikus elkepzelesek mellett x86/rpi vonalon. Az zseni lenne!kaef2 írta: ↑2026.06.23., kedd 17:42Egy jó barátom kora tavasszal kb két hét alatt összerakott egy komplett, Androidot kiváltó operációs rendszert, ami futtatható gyakorlatilag minden Android kompatibilis eszközön. Minden benchmark szerint nagyszerűt alkotott, már van rá befektetői érdeklődés katonai és kórházi vonalról is, külföldről. Talán lesz rá hazai érdeklődés is.
Hatha lenne egy ilyen, audio specifikus elkepzelesek mellett x86/rpi vonalon. Az zseni lenne!kaef2 írta: ↑2026.06.23., kedd 17:42Egy jó barátom kora tavasszal kb két hét alatt összerakott egy komplett, Androidot kiváltó operációs rendszert, ami futtatható gyakorlatilag minden Android kompatibilis eszközön. Minden benchmark szerint nagyszerűt alkotott, már van rá befektetői érdeklődés katonai és kórházi vonalról is, külföldről. Talán lesz rá hazai érdeklődés is.
Egy jó barátom kora tavasszal kb két hét alatt összerakott egy komplett, Androidot kiváltó operációs rendszert, ami futtatható gyakorlatilag minden Android kompatibilis eszközön. Minden benchmark szerint nagyszerűt alkotott, már van rá befektetői érdeklődés katonai és kórházi vonalról is, külföldről. Talán lesz rá hazai érdeklődés is.
Lesz valami egyszerű GUI, ha minden igaz. És lesz batch processzálás is.Aszpirin írta: ↑2026.06.23., kedd 16:31Jó 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 AIHa 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
Ahh, es mar el is indult a fejlesztes. :( Akkor tablettel lehessen iranyitani. billentyuzet, eger felesleges, ugysem tudod megoldani ha problema van mert nincs mit annyira egyszeru software es ha a hardware rossz akkor egy masik gep kell. Lehet ujra ertekesek lennenek 10-20 eves gepek. :) Bar ha tablet akkor kell wifi, talan a blutoothos eger kombo billentyuzet jobb megoldas lenne.
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 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.... Ha jól értem, GUI-t nem is számsz ennek (?) Csak hogy izzadjon a hardver. (itt ényleg értelmet fog nyerni a "számítógép" kifejezés )Ez a konverter tervezett funkcionalitása:kaef2 írta: ↑2026.06.23., kedd 13:37Amikor 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 írta: ↑2026.06.23., kedd 13:12Való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!
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.juliush írta: ↑2026.06.23., kedd 15:17Fura 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.Aszpirin írta: ↑2026.06.23., kedd 14:24...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...
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.
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.Aszpirin írta: ↑2026.06.23., kedd 14:24...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...
É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.juliush írta: ↑2026.06.23., kedd 13:12Való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 írta: ↑2026.06.23., kedd 13:12Való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!