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

[kaef2]

Megjelent a számítógépes audióról szóló, itt is emlegetett cikksorozatom első része a híres amerikai hifi szakfolyóiratban, a Positive Feedback-ben.

https://positive-feedback.com/audio-dis ... ion-part1/

[kaef2]

Olvasgató a szoftver fejlesztésről írt cikksorozat harmadik része:

https://mediaengineering.medium.com/bit ... 8b948f5456

[kaef2]

Feri, ez a konverter SACD.ISO-t tud majd fajlokra szetkapni?
Koszi!

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.

Vagyis most még nem tud, de megoldható.

[wittao]

Feri, ez a konverter SACD.ISO-t tud majd fajlokra szetkapni?
Koszi!

[kaef2]

[kaef2]

Újabb funkciók kerültek be a HQConv audio file konverter alkalmazásomba (amit ugye LLM (AI) segítségével fejlesztek), pedig eddig sem volt szegényes a tudása. :)

Ha már van benne mérő rész, ami jegyzőkönyvet is ad a mérésekről, gondoltam lehessen ezt konverzió nélkül is használni. Így belekerült egy összehasonlító almenű is. Itt két hangfile-t lehet összehasonlítani és az egyezőségükről, vagy különbözésükről konkrét, mért adatokat kapni. Beépítettem egy szöveges leírást is a különbségekről, később ezt majd bekötöm LLM-ekbe is, és a segítségükkel bővebben ki lehet majd értékelni a látottakat. Látható a nullteszt eredménye is.

Alább egy DSD256 és a belőle készült 44,1kHz/24 bites konverzió összehasonlítását látjuk.
--------------------------------
[measure] A: /Volumes/T7/S_erno_smpl_shrt_v1_11.2M.dsf
[measure] B: /Volumes/T7/S_erno_smpl_shrt_v1_11.2M_converted_44k_v5.wav

==== Eredeti vs. Konvertált összehasonlítás ====
rms_error : 0.0000
rms_error_db : -139.3270
rms_error_rel_db : -115.7762
peak_error : 0.0000
peak_error_db : -126.4326
correlation : 1.0000
freq_resp_deviation_avg_db : -0.0000
freq_resp_deviation_std_db : 0.0006
thd_plus_n_db : -115.7762

---- Szint / hangosság (dBFS) ----
Eredeti Ch1: peak -7.14 dBFS RMS -23.55 dBFS crest 16.41 dB
Eredeti Ch2: peak -4.41 dBFS RMS -21.47 dBFS crest 17.06 dB
Konvertált Ch1: peak -7.14 dBFS RMS -23.55 dBFS crest 16.41 dB
Konvertált Ch2: peak -4.41 dBFS RMS -21.47 dBFS crest 17.06 dB

---- Hangosság (ITU-R BS.1770 / EBU R128) ----
Eredeti : -19.13 LUFS LRA 4.81 LU true peak -4.40 dBTP PLR 14.73 LU
Konvertált: -19.13 LUFS LRA 4.81 LU true peak -4.40 dBTP PLR 14.73 LU

==== Null test (A - B) ====
difference peak -126.4 dBFS, RMS -139.3 dBFS -> PERFECT NULL

==== DSD folyam-analízis (1.4 s, 11289600 Hz) ====
Ch1: DC +0.0002 ones-density 0.5001 max-run 3 ultrahang/audio +30.1 dB
Ch2: DC +0.0000 ones-density 0.5000 max-run 3 ultrahang/audio +30.3 dB

==== Értékelés / Assessment ====
A két fájl a hallható sávban gyakorlatilag azonos - a konverzió átlátszó, hallható különbség nincs.
In the audible band the two files are essentially identical - the conversion is transparent, with no audible difference.
PDF riport mentve: /Volumes/T7/S_erno_smpl_shrt_v1_11.2M.pdf

[kaef2]

Fejlődik az alkalmazás, elég szépen , bekerült pár új funkció is az elmúlt két napban.

A CLAP plug-in csomag használati lehetőség azt jelenti, hogy akár pro, akár home hifi esetében, ha akar valaki, akkor belenyúlhat, kvázi "remasterelheti" a konvertálandó file-t.

Még a kötegelt (batch) feldolgozást kell reszelgetni egy kicsit és agyalok azon, hogy valami nagyon egyszerű vágási lehetőséget is betegyek, hogy csak egy file bizonyos részeit is lehessen konvertálni, ne kelljen külső alkalmazás a szegmentáláshoz.
Utána kezdődik a komoly tesztelés.

Újdonságok:
- Natív CLAP audio-effekt pluginek támogatása a PCM láncban. Ez különlegesség, nem tudok más konverterről, aminek lenne ilyen szolgáltatása.
- 32/64 bites feldolgozás (automatikus)
- State/preset betöltés és mentés
- Latencia- és tail-kompenzáció
- Mintavételi ráta korlátozás (ha a plugin nem bírja a chain rate-et) – csak felhasználói jóváhagyással történik mintavétel konverzió plug-in használatkor

Mérés és Minőségbiztosítás
Teljes AES17/IEC 61606 jellegű mérési csomag mellé bekerültek az alábbiak:
- LUFS, LRA, True Peak (ITU-R BS.1770) mérések
- DSD-specifikus analízis (zajspektrum, ones-density, stb.) (ez is újdonság, nem tudok róla, hogy más app csinálná)
- Automatikus validációs tesztcsomag (tests/validate.py)

Felhasználói élmény további javítása:
- Hangosság normalizálás streaming platformokra (LUFS célok: Spotify, Apple, Tidal, stb.)

Technikai részletek
Platformfüggetlen: azonos forrás macOS + Linux
Telepítés: .dmg macOS-re, make install Linuxra

[kaef2]

A konvertálás energia és tárhely igényéhez pár adat.

Egy 2 TB-os külső SSD, USB C 3.2 csatlakozással, ismert gyártótól, kb 45 ezer forint az Alzában. Egy 2 TB-os külső meghajtón kb 197 óra DSD256 mintavételezésű anyag fér el (168 MB/perc). Ez kb 230-240 átlagos 50 perc hosszúságú album. Vagyis pár száz forintra jön ki egy DSD256-ra konvertált album tárolásának költsége. Nem tűnik nagyon drágának. 40 Ft/kWh óra energia költséggel és mondjuk 50W-os számítógép fogyasztással számolva kb 10 Ft lesz egy 50 perces album DSD256-ra történő konvertálásának költsége. Ha 100W-tal számolunk akkor a 6-szoros (valós időhöz képest) konvertálási idővel is kb 20 Ft lesz egy album konvertálásának költsége. Vagyis ez sem valami nagy dolog. Ha lesz időm megcsinálni a konverter egyidejű több szálon történő futását, akkor a mostani egyszálas futáshoz képest jelentősen felgyorsulva és egy picit többet fogyasztva, kb 40%-kal csökkenthető a gépidő és ezáltal a konvertálás energia költsége.

Az általam használt algoritmusok, szűrők konverziós hibája gyakorlatilag nulla, ezeket az adatokat méri a szoftver egy 44,k -ról 705,6 kHz-re elvégzett konverzió esetében és a csatolt ábrán látszik az eredeti és a konvertált különbsége (gyakorlatilag nincs számottevő különbség).

rms_error: 0.0000
rms_error_db: -86.6869
rms_error_rel_db: -66.8500
peak_error: 0.0021
peak_error_db: -53.5292
correlation: 1.0000
freq_resp_deviation_avg_db: -0.0000
freq_resp_deviation_std_db: 0.0000
thd_plus_n_db: -66.8500

waveform_overlay.png (46.51 KiB) Megtekintve 300 alkalommal

Még teszek bele hangosságmérést is, hátha ha valaki még több adatot szeretne kapni a konverzió eredményéről.

[kaef2]

Megvan a gui és működik a file konverzió is. A konvertált file-t hibátlanul megszólaltja a bpplay.

[kaef2]

Említettem már a bpplay lejátszó szoftver LLM segített fejlesztése kapcsán, hogy készül egy file konverter is. Örömmel jelentem, hogy az első érdemben tesztelhető verzió elkészült. Ráadásul macOS és Linux kompatibilis lett, mindkettő esetében futtatható a terminálban. A neve: HQConv. Csatolva látható a szoftverleírásból pár oldal. A figyelmesebb olvasók észrevehetik, hogy ez a megoldás a offline konverzióra optimalizált, vagyis semmit nem akar valós időben csinálni, inkább lassan, de biztosan. A jó minőséghez idő kell. :)

Szemben a kevés hasonló megoldással, implementáltunk (én és az LLM-ek) egy mérő modult is, ami részletes jegyzőkönyvet készít a konverzió eredményéről, ha a felhasználó kéri. Tud a mérő modul null tesztet is, vagyis képes összehasonlítani az eredeti és a konvertált file-t. Tud batch processzálást, vagyis képes sok tracket automatikusan feldolgozni. Tulajdonképpen ezek a funkcionalitások nem az átlag hifistának szólnak, inkább azoknak a professzionális hangfelvételkészítőknek, akik sűrűn kell, hogy konvertáljanak. Azok számára inkább, akik jelenleg a HQPlayer Pro verzióját használják.

A teljes funkcionalitású verzió biztosan nem lesz nyílt forráskódú. De egy fix konverziókat tudó lájtos megoldás valószínűleg igen. Például egy olyan, ami tud 44,1kHz/16 bitről DSD256-ra konvertálni, DSD64-ről 176,4 kHz/24 bitre konvertálni és 44,1kHz/16 bitről szintén 176,4 kHz/24 bitre.

Lesz valami egyszerű GUI is hozzá.

Alapvetően ez is csak egy kísérlet, most még. A DIY szoftver fejlesztés lehetőségeinek megismerése kapcsán.

[kaef2]

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. :)

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.

Hatha lenne egy ilyen, audio specifikus elkepzelesek mellett x86/rpi vonalon. Az zseni lenne!

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]

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. :)

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.

Hatha lenne egy ilyen, audio specifikus elkepzelesek mellett x86/rpi vonalon. Az zseni lenne!

[kaef2]

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. :)

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.

[kaef2]

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 )

Lesz valami egyszerű GUI, ha minden igaz. És lesz batch processzálás is.

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

Ne tudjon semmi mást? Billentyűzetet/egeret kezelni se? Monitort kezelni se?

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.
De igy mar kellene egy al topic is az uj software-nek, pl csevego vagy "hasznos" tanacsok/otletek. :)

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