Régi programok MP3 formátumba kovertálása, és betöltése Javascript segtségével

Probald meg a sox-szal a konverziot: `sox program.wav -c 1 -r 44100 program.mp3`, mindezt kulonbozo -r ertekek mellett (mmint ha ez nem jo akkor 48000 is johet). A -c 1 sem muszaj, de lehet hogy ez is szamit hogy mono legyen az mp3 stream. Lehet hogy a lame alapertelmezesben mono wav-vol is sztereo mp3-at csinal, ellenben a szimulator csak mono mp3-at szeret.

Két tipp:

1. Formátum: itt panaszkodik a költő, hogy a lame szabadon értelmezi a szabvány fejléc fogalmát

2. Az mp3 veszteséges tömörítés és az emberi fülre van kitalálva, lehet a default szűrő kidobott valamit amit te nem hallasz, de a gépnek hiányzik

Próbáld OGG/Vorbis-ba, esetleg OPUS-ba konvertálni. Ugyanazon a bitrátán jobb a minőség és emiatt nagyobb eséllyel eszi meg az emulátor.
Ha biztosra akarsz menni, akkor konvertáld át FLAC-ba, amit szükség esetén belerakhatsz OGG konténerbe is.

Vagy az is lehet, hogy az emulátor kezel valamilyen gazdaságosabb formátumot is. TVC-hez pl. "cas" kiterjesztésű fájlokat szokás használni, ami kb. a TVC saját diszk-formátuma.

soxi -val nézd meg a fájlokat - valószínűleg kiderül h mi a turpisság!

Az Audacity-vel ha megnyitod a két mp3 fájlt, vizuálisan kereshetsz benne különbségeket.
Lehet, hogy a jelszint nem megfelelő.

https://en.wikipedia.org/wiki/Category:Lossless_audio_codecs

Jókat ajánlottak itt előttem, de én másfele indulnék. Átkonvertálnám a kazettafelvételeket egy külön programmal bináris lemezképpé (ehhez tudni kéne pontosan milyen gépről van szó), és azt etetném meg az emulátorral, ha az nem eszi meg, akkor keresnék másik emulátort. Nem írtad, hogy milyen gép.

Ne már, ahogy fentebb is írták, az mp3 veszteséges, tökéletesen alkalmatlan erre.

Ha már mindenképpen hang, lehetne tömör wav is! Sokan azt gondolják, hogy a wav mindig tömörítetlen, de ez nem igaz, csak azt a formáját használjuk leggyakrabban. Gyors fejszámolással arra jutottam, hogy ha 1.6 ms a bitidő, akkor a 8 kHz-es mintavétel bőven elegendő, és teljesen jó lesz a telefonos tömörítés, ami valójában egy dinamika kompresszió, de az időzítéseket nem rontja el. Válaszd a G.711 A-law kódolást, ez 8 kB/s tárhelyet fog foglalni.

Bár tényleg nem tudom, miért nem az adatot tárolod, s miért nem írsz egy programot, ami adott esetben az adatból hangot generál valós időben.

Szerk.: Úgy számolom, még ennek a tömörített formátumnak a használatával is a tényleges adat a hangfile kevesebb, mint 1 %-a lesz, szóval tényleg nem tudom, miért nem a natív adatot tárolod.

Összedobtam neked gyorsba' egy kis toolt erre.
https://gitlab.com/bztsrc/cassette

Teljesen függőségmentes, csont nélkül fordul egy make-re.

Ha egy mp3-ból akarsz kiszedni egy programot, akkor

./cassette audio.mp3 program.bin

ha pedig egy bináris fájlból akarsz kazetta audiót csinálni,

./cassette program.bin audio.mp3

Alapból jól fog működni (128 kpbs, minden zéró bit a negatív tartományban), de flagekkel mindenfélét varázsolhatsz. Pl "-o 127 -z -64" hatására az egy bitek hangmintája maximum lesz, a nulla biteké meg a negatív tartomány felénél. Megadható ezen kívül még mindféle úri huncutság is, pl hogy a magnón 7 bit egy bájt, vagy hogy a magas vagy alacsony bitek vannak-e előbb, stb. A sample rate is megadható, bár azzal semmit sem csinál, csak beállítja a fejlécben.

Viszont minden, amit fentebb írtak az MP3 formátumról az igaz, de egyáltalán nem ezek miatt alkalmatlan a feladatra, hanem mert a codec ismeretlen mennyiségű csöndet rak a minták elé meg után. Ha teheted, használj inkább WAVE fájlt (azt is kezeli a program, egyszerűen csak ".wav" kiterjesztésű fájlokat adj meg). Persze ha az a JS emu csak mp3-at tud...

Egyébként mi az emulátor linkje? Nyílt forrású? A példa MP3-ak letölthetők? Az egyetlen Homelab 4 emulátor, amiről tudok, az sajna zárt forráskódú (https://homelab.8bit.hu/emulator.html) és az csak WAVE-t kezel, MP3-at nem is, és csak HTP programok tölthetők le hozzá (a linkelt HTP2WAV meg már 404).

Ps: Linux-ra írtam a proggit, de Windows-on is csont nélkül kell fordulnia mingw-vel (nem használ semmit). Ha szeretnéd, lefordíthatom Win-re, vagy wasm-ra és dobhatok rá egy webservice-t is akár.

Ha szépen akarom kifejezni magam, akkor alaposan leszoptam a harcifaszt ezzel a JS emulátorral...

Első dolog, hogy képtelenség lokálban futtatni, mert a fetch mindenképp hibát dob (hiába állítottam be az FF-nek, hogy ne tegye, meg lokálban egyébként se legyen CORS meg XSS ellenőrzés, akkor se megy).

Szóval, egy kicsit belenyúltam a kódba. index.html:

<input type="file" onchange="tape_from_file(this)">

A tape.js-ben pedig kicseréltem a "response" változót beolvasó fetch() sort egy FileReader-es wrapperre:

const localFileAsArrayBuffer = (file) => {
  return new Promise((resolve) => {
    const reader = new FileReader()
    reader.onloadend = () => resolve(reader.result)
    reader.readAsArrayBuffer(file.files[0]);
  })
}

const tape_from_file = async (url) => {
    const AudioContext = window.AudioContext || window.webkitAudioContext;
    var audioCtx = new AudioContext();
/*
    const response = await fetch(url);
    const buf = await audioCtx.decodeAudioData(await response.arrayBuffer());
*/
    const buf = await audioCtx.decodeAudioData(await localFileAsArrayBuffer(url));

    const ratio = cpu_freq / buf.sampleRate;
    const len = buf.length;
    const chan = buf.getChannelData(0);

    let cnt = 0;
    let sample = false;

console.log(buf, cpu_freq, buf.sampleRate, ratio, len, chan);
    return {
        get_cnt: () => cnt,
        get_size: () => len * ratio,

        tick: (dcnt, recording) => {
            cnt = Math.min(len * ratio, cnt + dcnt);
            const i = Math.floor(cnt / ratio);
            sample = chan[i] > 0.03;
console.log(cnt,i,sample);
        },
        write: () => { }, // TODO
        read: () => sample,
        rewind: () => { cnt = 0; },
    };

Így már be tudtam tölteni a hangfájlt, meg is ette, az első console.log szépen kiírta a dekódolt mintákat. De vannak komoly gondok:
https://i.ibb.co/m0tLKb7/ff-honlab.png
(Az első fetch hibát oldaltöltéskor írja ki, a többi sort miután kiválasztottam egy fájlt. A tape-filesel.js fájlhoz nem nyúltam, az az eredeti.)

Először is, nem tudom, miért hiszi, hogy a wav 48000Hz, mikor nagyon nem az.

$ ffmpeg -i tartalom.wav 2>&1| grep Audio
  Stream #0:0: Audio: pcm_u8 ([1][0][0][0] / 0x0001), 44100 Hz, 1 channels, u8, 352 kb/s
$ hexdump -C tartalom.wav | head -4
00000000  52 49 46 46 2c ce 07 00  57 41 56 45 66 6d 74 20  |RIFF,...WAVEfmt |
00000010  10 00 00 00 01 00 01 00  44 ac 00 00 44 ac 00 00  |........D...D...|
00000020  01 00 08 00 64 61 74 61  00 ce 07 00 40 40 40 40  |....data....@@@@|
00000030  40 40 40 40 40 40 40 40  40 40 40 40 40 40 40 40  |@@@@@@@@@@@@@@@@|

Ez egyszer probléma. A másik, hogy az is jól látszik, 48000Hz esetén a ratio 83.3333333333333, tehát a kerekítési hiba garantált. Az adatok egyébként megvannak, szépen float-á konvertálódtak, szóval ez nem para. (Azt mondjuk nem értem, hogy lett a sok egyforma 0x40 értékből ennyi különféle float érték. Lehet, hogy az AudiContext forcefully átskálázta 48000Hz-re a mintákat? Ha igen, akkor eleve felejtős, hogy jó pozícióra esnek az értékek... Ez esetben csak 48kHz wav-val szabad eleve próbálkozni, azt talán egységesen alakítja floattá.)

Aminél viszont végleg feladtam, a második console.log sor, aminek "tick" hook hívásakor kéne logolnia, na az még csak ki sem íródik. Ez azt jelenti, hogy hiába tölti be a mintákat az AudioContext, azt ez a JS soha még csak nem is értelmezte... Na ennyire már nem vagyok mazochista, hogy még ezt is kidebuggoljam...

Ez az emulátor jelen formájában egyáltalán nem képes semmilyen hangfájlból programokat betölteni, pont.

Megnéztem a másik emulátort is (gaia.atilia.eu-st). A wav-ot sikerült felcsatolni vele, felismerte (menü > Magnó > WAV csatolása). Parancsba beírtam, hogy "LOAD", majd enter (ez kínszenvedés volt, mivel minden 30-40 karakterleütésből egyszer fogadta csak el...). Aztán minden hibaüzenet nélkül lefagyott? Legalábbis nem történt semmi, csak a kurzor nem villogott tovább. Próbálgattam különböző menüpontokat, erre meg GenProt és crash.

(Ja, egyébként a "bit's length"-et 72-re kell állítani, akkor pont olyan hosszú lesz a wav, mint a htp2h2wav proggival.)

Én is próbálgattam, az FPGA-s Homelab-emulátorommal (bár ez is nem is emulátor):

Az mp3-akat meg se érzi, WAV-ot meg nem találtam sehol. Bár az én emulátorom szerintem nem model III meg IV, hanem a legelső.

Szerk.: próbaképp megnéztem Spectrummal is, tape2wav-val csináltam tzx-ből egy wav-ot, mplayerrel lejátszottam az FPGA-nak, betöltötte. Majd lame-el átkonvertáltam mp3-ra, első próbálkozásra nem ment. A nyitóban látott -s 44.1 -b 96 -q 9 -m m
 kapcsolókkal viszont működött.

Na, frissítettem a repót meg a webservice-t is. Bekerült egy csomó minden. Mivel lusta vagyok alapból, ezért lett preset választó, hogy ne kelljen mindig felkattogtatni a Homelab paramétereit.

1. az általam generált wav és mp3-akat stabilan konvertálja oda-vissza
2. mind az mp3-at, mind a wav-ot hiba nélkül betölti az emulátor
3. ha a betöltött wav-ot le tudja futtatni az emulátor, akkor a betöltött mp3-at is.

Azonban nem fenékik tejfel minden, a rövid programok (hello, tehen) tökéletesen futnak is, viszont a hosszabbaknál (pl bombazo), előbb-utóbb szétcsúszik a szinkron, és a program végére zagyvaságot tölt be. Hogy ezt miért nem veszi észre az emulátor, és miért nem dob rá error-t, az passz. Nem erre lenne a checksum a végén?

Szóval a betöltés hiba nélkül lefut, de ha kiadom a LIST-et, akkor csak a program eleje jó, egy idő után átcsap másnapos ASCII artba. Ez tuti, hogy az órajel / frekvencia kerekítési hibákból adódik, valahogy vigyelembe kell vennem ezt a generáláskor.

Szóval alakul, de még van mit csiszolni rajta. A hello.mp3 és a tehen.mp3 már tökéletes. (Megj: kézzel beraktam a kódba, hogy a 7. bittől kezdje, így lett hello.htp-m, abból generáltam. A TEHEN.wav-ot csont nélkül és hibátlanul mentette tehen.htp-be.)

> A tüskék hosszának nem lenne szabad néhány mintánál tovább tartani. A biteket a szünetek hossza kódolja.

Hát biztos nem. Mármint értem, hogy elvileg így kéne lennie, a JS emulátor nagyon nem így működik, az biztos.
Ha tényleg a felfutó éleket figyeli, a biteket akkor sem a szünet kódolja, szóval a szélesség tök mindegy (amíg az nagyobb, mint a mintavételezési gyakoriság). Ha érdekel, a megadott bithosszt (length) két részre bontom, set-re és stop-ra. A set részbe kerül a magas jel, ha a bit egy, a stop rész meg mindig az alacsony szint. https://gitlab.com/bztsrc/cassette/-/blob/main/encode.c#L72 Ha túl vastag neked a tüske, akkor e két változó arányával könnyedén állítható. Lehet berakok egy kapcsolót, amivel meg lehet majd ezt adni.

> Én csak mintaértékeket írok ki egy wav fájlba egymás után, azt még tudom követni.

Én se csinálok mást. A külső ciklus végigmegy a bájtokon https://gitlab.com/bztsrc/cassette/-/blob/main/encode.c#L91 (i a bájtszámláló, l az ezidáig kiírt hossz)
Aztán a belső ciklus végigmegy a biteken https://gitlab.com/bztsrc/cassette/-/blob/main/encode.c#L93 (nb = number of bits, ez Himelabnál mindig 8)
A cikluson belül ha kell prefix szinkronjel (sy & 1), akkor kitesz set hosszan magas jelet, majd stop hosszan alacsony jelet (Homelabnál ez nincs).
Aztán kikerül az adatbit, hasonlóan set hosszan magas vagy alacsony jel a bit értékétől függően, majd stop hosszan alacsony jel.
Végül ha suffix szinkronjeles (sy & 2), akkor kitesz set hosszan magas jelet, majd stop hosszan alacsony jelet (Homelabnál ez mindig van).
Kb. ennyi.

Ez viszont nem jó megoldás. Az a baj vele, hogy diszkrét számú mintát tesz ki minden bithez, holott a beolvasáskor (elvileg) időarányosan számítódik ki, hogy hányadik mintából kell olvasni, ezért a kerekítési hibák miatt a bitek hosszának változnia kéne a hangmintában, különben elcsúszik a jel egy idő után (a kerekítési hiba nagyságától függően N minta olvasás után már az N - 1. vagy N + 1. mintát fogja olvasni az N. helyett, ami nyilván nem jó).

Ezen dolgozom most épp, hamarosan kész. A beolvasást már feltúrbóztam. Kidobtam a high-pass filtert, mert semmi értelme, bekerült helyette egy hullámnormalizáló, és egy kis heurisztika, ami képes felismerni a fejlécet (ami a 256 nulla bájtot előzi meg, és vagy van, vagy nincs a mintáitokban. Ha van, akkor mindig az első bájt legmagasabb bitje az első igazi adatbit, egyébként a legalacsonyabb bitjével kezdődik). A normalizálás azért kellett, mert nagyon sok minta elnyűtt szalagról származik, ezért elég viccesek, itt egy kép, hogy lássátok miért volt gigaszopás: https://i.ibb.co/RY0PDBH/magnorol.png

Az eredmény, hogy minden hangmintát, amit linkeltetek, atomstabilan konvertál htp-vé. Még a kerekítési hibás cuccot kijavítom a generálásnál (esetleg vékonyabbra teszem a tüskét), és feltöltöm a javított változatot.

> Már kíváncsi vagyok arra a ROM rutinra, hogy érzékeli a tüskéket

Igen, most már én is. Lehet ráeresztem a diszasszemblálómat, anno csináltam hozzá Z80 utasítástáblát is (bár csak pár triviális tesztet futtattam rá, ha az emlékem nem csal). https://gitlab.com/bztsrc/udisasm

Én egyébként nem foglalkozom a felfutó élekkel (csak FM kódolás esetén). AM kódolásnál ha van szinkronjel, akkor egyszerűen megkeresem azt a mintaközt, ahol minden szinkronbit magas jelű, ezt lefelezem, és ezután egyszerűen minden ennyedik mintát nézem, hogy magas vagy alacsony jel-e. Ez remekül működik az összes eddigi beszerzett mintára (igen, még azoknál az mp3-aknál is tökéletes, amik a JS emuhoz voltak, de a JS emu sem volt képes beolvasni, pl. hoki.mp3 vagy hello.mp3)

Na kérem, frissítettem a repót és a webservice-t: https://bztsrc.gitlab.io/cassette/

Ez most tutibiztos, bármilyen hangmintát, amit csak adtatok, magabiztosan és hiba nélkül konvertál htp-vé (a legrosszabb, amit láttam, hogy pár extra nulla bájtot rakott a végére, ha a proggi után még volt valami nagy zaj a hangmintában).

A másik irány is megy, minden általa generált mp3-at csont nélkül beolvas az emulátor. Példák itt találhatók: https://gitlab.com/bztsrc/cassette/-/tree/main/examples

Akad néhány htp fájl, ami hiba nélkül betöltődik, azonban a listázásra kriksz-krakszok jelennek meg. Kicsit összehasonlítgattam a binárisokat, és arra jutottam, ez nem a generáló vagy a betöltő hibája, hanem valószínűleg ezek nem Aircomp 16 kompatíbilis programok (hanem Homelab 3 vagy ilyesmi). Az egyik ilyen az a hoki.mp3 és hoki.wav, amit a JS emu mellé adtak, megjegyzem abból a wav-ot sem tudta lefuttatni. A htp-t gyönyörűen ki tudtam nyerni belőlük, és az abból generált mp3-amat is hiba nélkül betölti, de aztán ugyanaz, mint az eredeti wav esetében, nem listázható és nem futtatható.

Ha valaki parancssorból akarná használni, akkor annyi változott, hogy eddig a bithosszt -l kapcsolóval minták számában kellett megadni. Ezentúl μs-ben (milliomod másodperc). Alapból a vicces fejléceket detektálja, és nem generálja, de a -h hatására kihagyja a detektálást, ill. generáláskor mindig beteszi.

Gyorssegítség:
audióból htp:

./cassette -2 aircomp_proggi.mp3 aircomp_proggi.htp

htp-ből audió:

./cassette -2 -l 771 aircomp_proggi.htp aircomp_proggi.mp3

Nem próbáltam, de valószínűleg tökéletesen működik az összes többi Homelab emulátorral és igazi vassal is. Az biztos, hogy az audió-htp irány minden körülmények között operában volt megy, és esélyes, hogy a htp-audió iránynál is max pár kapcsolón kell csak kicsit tologatni.

Használjátok egészséggel!

ps: próbáltam -32-vel, a legtöbb esetben ment, de pl. a hoki.mp3-nál nem volt elég (betöltési hibát eredményezett), ezért hagytam -64-en az alapértelmzést, de nyugodtan próbálgassátok -32-vel.
ps2: ja és igen, a tüskék szélességét benéztem, eredetileg fordítva akartam: bithossz 1/4-e a szignál, 3/4-e az üres, nem fordítva. Ez is javítva lett.

> nézd csak, homelab 4 gépkönyv 51-edik oldal, leírja a kazetta kezelést

Ezt jó lett volna látni korábban :-) Sajnos az általatok linkelt hangminták azonban nem felelnek meg az itt leírtaknak. E szerint a fejléc 256 darab nulla bájt, csakhogy a valóságban a fejlécek ilyenek (a képen az alsó három hullám):
https://i.ibb.co/RY0PDBH/magnorol.png
Azaz van pár bit (néha 1 rövid, 1 hosszú, 1 rövid vagy inkább 1 hosszú, 1 rövid csoport, majd üresség, de egyszer olyan is előfordult, hogy 1 hosszú, üresség, 1 rövid csoport). Empirikusan arra is rájöttem, hogy ha van ilyen fejléc, akkor az 7 bitnyi, szinkronjel nélküli 0 bitnek felel meg, tehát a legelső szabályos (a leírásban is szereplő) adatbit ilyenkor nem az első bájt legelső, hanem az első bájt legutolsó bitje. Ezt követi 255 darab szabályos nulla (a második szabályos adatbit már mindig a második bájt legelső bitje), majd a 0xA5. Tehát a legelső nulla bájt kódolása nagyon nem olyan, mint ami a leírásban szerepel, a többinél már stimmel.

> A négyszög 0,19 ms ideig tart. Az első és harmadik kezdete közt pedig 1.5 ms telik el.

Ez sem igaz a megadott mintákra. A legtipikusabb 44100Hz, ahol az első és harmadik négyszög kezdete (két szinkronbit) között 34-36 minta van, tehát nem 1.5 ms, hanem 34 * 1/44100 = 0.000771 szekundum, azaz 771 mikroszekundum telik el. A tüskék hossza pedig nagyon ingadozik, szóval az sem 0.19 ms.

> Több mintát vesz és ha legalább 3 azonos egymás után, akkor veszi négyszög tetejének és a sebességhez is dinamikusan tud igazodni

Ez jó trükk, én is hasonlót csinálok. Megnézem, mi a legnagyobb és legkissebb érték a mintákban, aztán normalizálom: ami a legnagyobbhoz áll közelebb, abból mind teteje lesz, ami meg a legkissebbhez, abból mind alja (a fenti képen a felső három hullámot kezeli ez, amikor a függőleges zérus elmászkál meg az alja a pozitív tartományba lóg néha). Ezután megszámolom, hogy a felfutó élek között mennyi minta a különbség, és hogy az hányszor fordul elő, majd a leggyakoribbat veszem. Így a sebességtől tök függetlenül határozom meg, hogy hány minta hosszú egy bit. Ez tök jól működik bármilyen hangmintára, hacsak nincs túlsúlyban a zaj. (Egy kicsit összetettebb az ellenőrzésem, mert a leggyakoribb távolságra megnézem, hogy mindig kijön-e a magas szinkronbit, és ha nem, akkor a második leggyakoribb közt veszem, és arra szintén leellenőrzöm ugyanezt.)

Na, most már csak az a kérdés, hogy plt kolléga tudja-e használni.
Mégegyszer, ez csak bináris és audió között konvertál, tehát a htp előállítása BASIC-ből továbbra is Rád és a h2bas2htp programodra marad.

> Gondolom az a hivatalos sebesség, amit leírtak.

Igen, csak épp az összes linkelt mintában jóval kevesebb a bithossz a megadottnál. Engem mondjuk nem zavar. Egyébként megpróbáltam még ennél is kissebb bithosszal, az emulátornak az sem okozott gondot, de nem tudom, hogy igazi vason végül működne-e. Mindesetre így az audiófájlok mérete (és a betöltési idő az emulátorban) drasztikusan lecsökkenthető, ha más nem, a tesztelés idejére mindenképp megéri alacsonyabbra venni.

A Z80 nekem annyira nem jött be, mert C=64 volt az első gépem, és a 6502 jobban tetszett. De ezek a magyar gépek megérdemelnének nagyobb figyelmet, még ha Z80 proci van benne, akkor is. Kedvet kaptam építeni egy modernizált változatot. Nem túl bonyolult a felépítése, amennyit láttam a kapcsolási rajzok alapján. Mai modernebb integrált áramkörökkel is megépíthető lenne szerintem.