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

A kifejezetten erre készített formátumok az adatot tárolják és a paramtéreket, amivel előállítható hangként a gépnek megfelelő formátumban az adat.

Ez azt is jelenti, hogy semmi sem zárja ki azt, hogy audiót generálj belőle és azt használja az emulátorod. 
https://www.youtube.com/watch?v=MAIsOIwgJWA
Úgy látom tzx-hez van javascript hang generátor http://kmp1.github.io/tzx.js/

Nem írtad, hogy milyen 8bites kazetta, milyen géphez. Hogy saját írású vagy mástól felhasznált emulátor. 
Gondolom nem hátrány, ha sokkal kisebb méretű is a "kazetta", mint hangfájlként. Meglepne, ha valaki nem készített volna már olyat vagy nagyon hasonlót a számodra szükséges formátumból is.

Próbáld meg FLAC-ba, ha abból se megy, akkor nem az MP3 konverzióval van a baj. Egyébként érdekes ez a loader, nem tűnik túl megbízhatónak, vajon hogyan érzékeli a tüskéket? A népszerű gépek (C64, Spectrum, CPC) mind négyszögjelek felfutó (vagy lefutó) éleit detektálják.

A jelalakaidon látszik, hogy a működő MP3-ban valamivel szélesebb impulzusok vannak, azt talán könnyen elkapja a loader, míg a nem működőben gondolom van olyan, ami túl keskeny ahhoz, hogy észlelje.

Az mp3 nem különösebben alkalmas erre, mert frekvencia tartományban dolgozik, a fázist akár teljesen el is dobhatja, az emulátornak pedig szüksége van rá. De ettől még működhet is, csak amolyan szerencsejáték. Én is ezt javasolnám: https://hup.hu/comment/2956670#comment-2956670

Én a js-t megpróbálnám debuggolni, hogy mit csinál, megpróbálnám kiíratni a detektált biteket, és abból látszana, hogy teljesen homály (pl nem egyező mintaidő), vagy időnként téved (tömörítésből adódó hiba), vagy mi a fene van?

Egyébként ez egy nagyon nem optimális adat-tárolási mód, de gondolom tudod :-) Ésszerűbb volna digitálisan tárolni a fájlokat és ha kell a feeling, akkor hanggá konvertálni on-the-fly és lejátszani a usernek, ha meg nem kell, akkor teljesen kihagyni ezt a dolgot a buliból.

Ha megnézed a felsőt a 0-nál van a zaj. Az alsónál kb -1dB. 

Ránézésre a következő lehet a baj: a loader-ed null átmenetet (zero cross) keres és az alapján mér bitidőt.

Az első képen a wav érdekes, de akár működhet is, mert a null átmenetet lehet világosan látni. Nem konkrétan 0 jelszintnél kicsivel fölötte egyértelműen eldönthető, hogy 0 vagy 1.

A második képen eléggé „zajos” mert sokat „lebeg” a nulla közelében, emiatt a mérés mindig újra indul sok hibás bittel.

A harmadik megint tiszta jel, mert a fekete vonal keresztezésekor a mérés helyes értékeket ad. Itt is egyértelmű 0 vagy 1 van.

Próbaképpen, próbáld a második jelalakodat eltolni lefelé és akkor nagy valószínűséggel működni fog.

Nagyobb bitrattel nem próbáltad? 192 pl.

lame -s 44.1 -b 96 -q 9 -m m program.wav program.mp3

miért a leggyengébb minőségben csinálod? -q 0 a legjobb minőség

Az eredeti wav mono volt-e, ha nem, akkor -m m -a paraméterezést ajánl, hogy jó legyen a mono. 

a manuál alapján https://svn.code.sf.net/p/lame/svn/trunk/lame/USAGE

Az AudioContext meg alapértelmezetten azon dolgozik, amire a hangkimeneted állítva van. Gondolom átkonvertálja.
"the options are not specified when creating the audio context, the new context's output device's preferred sample rate is used by default."
https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/AudioCont…

Ha csak ez volt a baj, akkor legközelebb érdemes a manuállal kezdeni :)
De továbbra is értelmesebb lenne rendes formátumot használni és azt konvertálni hanggá, ha kell. Ha más nem valaki már csinált hozzá http://madmac.hu/8bit.hu/homelab/?q=node/5

Hú, az húzós lesz, ahhoz nem sok emulátor és konverter van. Azt hittem, valami népszerűbbről van szó, C64, ZXSpectrum vagy hasonló.

Ha tényleg csak annyi a tömörítés, hogy fft, aztán eldobja a magasabb frekvenciájú együtthatókat, majd inverz fft, akkor még rendben is van. Viszont emlékeim szerint például a Dallas DS2130 bár nagyon hatékonyan tömörített, az olyan fázishibákat, értsd, fázisugrásokat okozott a hangban, amitől kásás vacak lett az egész, az ilyen FSK szerű modulációt teljesen megöli. Az emberi beszéd azért marad érthető, mert sok periódusnyit mormog az ember az adott hangból, ha közben van fázisugrás, attól még világos a mormogás tónusa. Illetve az emberi agy kiegészíti a hangból hiányzó részeket.

egyébként htp (homelab 3 4) forműtumú programok ezen az sd kártyán is vannak https://retroemu.hu/z80tape.php

És itt mégtöbb minden
https://nattila.hu/index.php/homelab/homelab-rm32/6-homelab-rm32

Legörgetve a vége felé, a google drive linken ott van htp és wav is némelyikből

Egyelőre nem sok sikerrel töltögetem a wavokat (sem), azt, hogy mit hoz ki belőlük a gép, nem látom (a hardware csak a bitet látja, abból értelmes byteokat a ROM csinál), debuggolni kellene a ROM rutint (ami FPGA-n annyira nem egyszerű). Annyit látok, hogy vagy FE, vagy FF-t olvas a CPU a bemenő jelszinttől függően a load rutinban, szóval ez a része szerintem jó.

Még megpróbálom visszatölteni azt, amit a SAVE parancs lement, csak épp nincs kéznél jack-jack kábelem, hogy felvegyem.

Csatolom ide egy képet, amin felül az általad generált wav van, alul meg egy, a specifikáió szerinti wav. 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.

Már kíváncsi vagyok arra a ROM rutinra, hogy érzékeli a tüskéket, mert szerintem ez így elég megbízhatatlan, könnyű elszalasztani egyet-egyet. Az, hogy kb. négyszögjellel is működik, inkább arra utal, hogy felfutó éleket detektál, hogy két él közt mi van (azaz hogy milyen széles egy impulzus), nem érdekes. Illetve annyiból érdekes, hogy elég széles legyen ahhoz, hogy észrevegye a 0->1 átmenetet (mert ha túl keskeny, és a két szélén levő csendből vesz mintát, akkor máris hibás a beolvasás).

Ezt a teóriámat alátámasztja, hogy az FPGA-s Homelabom bzt wav-jában már megtalálja a fájlnevet.

Szerk.: https://easyupload.io/zuyjcz egy wav, amit a SAVE paranccsal mentettem (de visszaolvasni már nem tudom - az FPGA bemenetén van egy optocsatoló - MIDI-nek készült igazából -, valószínű nem elég gyors ezekhez a keskeny tüskékhez).

Mert működhet szerencsés esetben, de nem kell működnie.

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 ratio = cpu_freq / buf.sampleRate;
    const len = buf.length;
    const chan = buf.getChannelData(0);

    let cnt = 0;
    let sample = false;
+   let avg = 0;
+
+   for(var i = 0; i < len; len++) avg += chan[i];
+   if(len) avg /= len; else avg = 0.03;

    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;
+           sample = chan[i] > avg;
        },
        write: () => { }, // TODO

Modernizált alatt azt értem, hogy a ma is kapható integrált áramkörökből felépíteni. A billentyűzetet megcsinálni valami modern mechanikus kapcsolókból pl. Vagy akár felületszerelt kivitelben kisebb méretben.

Ahogy bzt kolléga is írta lentebb, ennek nem sok köze volt a két processzorhoz. A C=64 "multimédia" képességeit a VIC-II és a SID adta. Tovább árnyalja a képet, hogy a Sega és az SNK Z80-at használt például a Sega Mastersystem, Game Gear, Neogeo Pocket (Color) konzoljaiban. Ill. később mikor 68000-ra váltottak, a Z80 audio társprocesszorként volt jelen ezekben a gépekben.

Az Amiga sajnos a Commodore rossz üzletpolitikájának köszönheti a "halálát". Bár nem nevezném halálnak. Olyan képességei voltak már akkor, amiről a PC-k csak álmodtak. A Zorro busz például, vagy a méltán emlegetett audio és video képességek.