Re: Mr ToutLeMonde et la programmation NES...

[upsilandre]

ok merci
C'est sure que le confort d'avoir des ROM dédié comme sur NeoGeo ca serait autre chose.

[upsilandre]

Bon aujourd'hui je suis retourner sur Python pour coder le script qui me transforme le .wav (8bit bridé a 7bit) de Keziah Jones en ADPCM 4bit pour la NES. Il me sort a la fois un fichier raw qui contient la succession de delta ADPCM dont j'ai besoin pour la NES mais aussi un fichier .wav reconstruit a partir de ces data pour avoir tout de suite le resultat a l'ecoute (et surtout pouvoir visualiser la wave source avec celle ci l'une au dessus de l'autre et comparer)

Ca fonctionne pas mal. Ca absorbe plutot bien les gros changement d'amplitude a haute frequence (le sample de Keziah est assez exigent) tout en gardant la precision quand c'est calme. C'est pas exactement l'original forcement mais ca passe bien.

https://2img.net/h/s19.postimg.cc/okxuqrsqb/ADPCM4bit1.png
https://2img.net/h/s19.postimg.cc/dzdzermer/ADPCM4bit2.png
https://2img.net/h/s19.postimg.cc/4g4alaywj/ADPCM4bit3.png

En haut c'est la source et en bas c'est la version apres compression par mon algo ADPCM (qui prend donc 2 fois moins de place).

Mais la c'est la version 44khz du sample et malgres que ce soit de l'ADPCM tres basique (a vrai dire je connais pas d'algo ADPCM, j'ai juste pris le terme "adaptative" au pied de la lettre et fait a ma sauce car de toute facon j'aurais tres peu de budget CPU sur NES, ca laisse pas 36 solutions) meme si simple y a peu de chance que je puisse coder mon algo de décompression ADPCM sur NES pour du 44khz (ca veut dire un budget de 40 cycles CPU par sample). Le bute c'est plutot de viser le 22khz donc faut que je vois ce que ca donne en 22khz.

[Stef]

Ca me rappelle vraiment ce que j'ai fait sur MD sauf que moi c'était 2 canaux à 22 Khz en DPCM 4bit. Mon outil de conversion fait la même chose que le tien, il sort le sample en raw 4 bit DPCM et le wav avec la perte pour écouter tout de suite le résultat. J'étais assez étonné des faibles pertes même avec un DPCM (j'ai fait ma propre table de delta ^^) qui est un moins performant que l'ADPCM. Je pense modifier le driver pour passer à du ADPCM (toujours 2 canaux @22 Khz), il me restait peu de CPU avec la version DPCM (environ 10/15%) mais en passant avec des LUTs ça ne devrait pas me couter beaucoup plus.
J'ai regardé tes waveforms, les pertes sont très bien contenues sur les 2 premiers, un peu moins sur le dernier (en même temps il est ardu). J'aurais bien testé mon DPCM sur le même sample, tu as le WAV quelque part ? :)

[upsilandre]

J'ai ca pour la version 8bit
https://drive.google.com/open?id=0B399kteofpYuOWVoU2F0blltWTA

C'est vrai qu'avec une table en DPCM ca doit bien marché aussi (pour eviter d'avoir un delta linéaire j'imagine) faudrait que j'essaie. t'as mis quoi comme valeur dans ta table?

[Stef]

Ma table de delta :
{ -34,-21,-13,-8,-5,-3,-2,-1,0,1,2,3,5,8,13,21 }

Sinon voici le résultat de la conversion (en haut la version DPCM, en bas la version original). J'ai pris un passage qui fait bien mal avec des deltas très fort alors que ma table DPCM est plutot optimisée pour les petits deltas... on voit que les pertes sont importantes mais à l'oreille ça ne passe pas si mal curieusement.

[upsilandre]

Elle est pas mal ta table.
Moi mon ADPCM est tres simple. Les delta sont linéaire (-8 a +7), J'ai un coef d'amplification. Quand j'ai un delta superieur a 4 ou inferieur a -4 j'incrémente le coef d'amplification pour les delta suivant (j'applique alors un shift, donc un x2, aux delta suivant, ca double l'amplitude et divise par 2 la resolution.), si le delta suivant est encore superieur a 4 (donc a 8 apres amplification) ou inferieur a -4 alors j'incremente encore le coef d'ampli (x4) ect...  (Pour eviter d'accumuler les shift on peut effectivement pointer une table) et a l'inverse chaque fois que le delta est compris entre -4 et 4 je decremente le coef d'amplification.

Mais on pourrait combiner une table de delta non linéaire et l'amplification mais je verrais plutot alors une table de base plus soft genre -23, -17, -12, -8, -5, -3, -2, -1, 0, 1, 2, 3, 5, 8, 12, 17 ( meme moins je pense: -18, -13, -9, -6, -4, -3, -2, -1, 0, 1, 2, 3, 4, 6, 9, 13 en bornant toujours l'amplification audela de [-4,4] ca peut etre pas mal comme combinaison). Je sais pas si ca serait forcement pertinent de combiner les 2, ca aurait des avantages et des inconvénient mais faut tester.
Apres y a plein de combinaison possible aussi sur ou placer les curseurs d'incrementation/decrementation de l'amplification. Mais a defaut de passer du temps et de trouver la solution idéal vaut mieux choisir ce qui prend le moins d'instruction je pense.

[upsilandre]

Ou sinon garder des valeurs linéaires mais avoir une seconde table symetrique a celle des delta qui contient les valeurs d'incrementation de l'amplification correspondante (qui lui meme peux servir de pointeur vers les autres tables de delta) du genre +2, +2, +1, +1, 0, 0, -1, -1, -1, -1, 0, 0, +1, +1, +2. Ca permettrait plus de nuance dans l'amplification.
y a une infinité de combinaison possible.

[Stef]

Ma table est assez simple en fait, je calcul le delta suivant en prenant la somme des 2 précédents en partant de la base [0,1,2] ou en ajoutant la moitié arrondi au supérieur (ça revient au même)
Sinon il y a effectivement pas mal de méthodes pour l'ADPCM, dans mon cas je pensais à une espèce de table 2D:

Code:

0   --->   15
[high to low negative delta]
[high medium negative to 0 delta]
[medium negative to low positive delta]
[balanced delta]    --> correspond à ma table actuelle
[low negative to medium positive delta]
[0 to high medium positive delta]
[low to high positive delta]


Bon je ne sais pas si c'est très claire mais en gros tu commences sur la "balanced delta" et ensuite en fonction de ton offset dans la table :
[0-3] --> on passe à la table -1 (si possible)
[4-11] --> on reste sur la table actuelle
[12-15] --> on passe à la table +1 (si possible)

L'inconvénient de cette méthode est que tu bouffes plus de place avec les LUT (surtout que dans mon cas je traite 2 samples à la fois, donc la LUT de base est au carré)

[upsilandre]

Oui c'est un peu comme ca que je voyais le truc. Par contre je suis pas convaincu par les valeurs. Quand t'es dans une phase a haute frequence tu vas enchainer des monter rapide et des descentes rapide qui s'enchaine successivement d'un sample a l'autre sans transition.
La dans ton exemple pour passer d'une monter rapide a une descente rapide c'est tres compliqué, ca va ecraser toutes les  haute frequence. je pense que des tables linéaire (qui change juste d'amplitude et de résolution) c'est peut etre mieux (donc avoir au sommet plutot une table low-res de type [high negative to high positive] car l'un va souvent avec l'autre.) ou alors des table non linéaire mais symetrique par rapport au zero .

[upsilandre]

J'ai fais un test vite fais et c'est deja mieux qu'hier

Hier j'etais donc sur une table delta de base linéaire [-8, +7]. Une table qui evoluait selon un multiplicateur qui lui meme evoluait selon le delta precedent de cette facon simpliste [x2 ,x2 ,x2, x2, :2, :2, :2, :2, :2, :2, :2, :2, x2, x2, x2]

La j'ai gardé une table de base linéaire [-8,+7] mais le multiplicateur de la table evolu maintenant de cette facon [+2, +1, +1, +1, 0, 0, -1, -1, -1, -1, -1, 0, 0, +1, +1, +2]
Donc ca me donne des table avec des multiplicateurs plus fin qui montre moins vite par incrementation (x2, x3, x4, x5 ect... au lieu de x2, x4, x8... hier, du coup faudra forcement passer par des tables, le simple shift de registre ne suffira plus mais c'est pas plus mal) compensé par le fait qu'on peut franchir 2 multiplicateurs d'un coup avec les delta saturé (-8 et +7 donne donc une incrementation +2 du multiplicateur, ce qui veut dire qu'on peut passer d'un multiplicateur x1 a x3 d'un coup pour des démarrages rapide)

Resultat c'est clairement mieux, en tout cas visuellement en superposant les 3 waves celle de ce nouveau algo est chaque fois clairement plus proche de la source que ma version d'hier, y a pas photo. Du coup je peux deja virer celle d'hier pour garder celui ci comme référence pour d'autre teste. En l'etat ca me convient deja plutot bien. A voir avec des table de delta non linéaire.

PS: a titre indicatif sur ce sample le multiplicateur monte jusqu'a x10 (2 fois seulement, et x9 une 40ene de fois, x8 285 fois)

[Stef]

C'est plutot pas mal ce que tu as trouvé... Et effectivement l'exemple que je t'ai donné n'est pas bon. Ca serait plutot simplement des tables avec des deltas plus ou moins grands. Après y'a des tonnes de manière d'arranger les tables et la manière de naviguer dedans, je pense que ta solution est déjà très bien. Perso j'opterai probablement pour des deltas non linéaires malgré tout mais le résultat final ne doit pas être très différent

[upsilandre]

J'ai fais pas mal de tests depuis la derniere fois et divers constat.

- le DPCM 4bit avec une table exponentiel (et donc une large variété de "pente") ca marche vraiment bien surtout que sur NES t'es en resolution 7bit donc c'est vraiment plus que suffisant. Impossible a discerné de l'original pour moi. Y a vraiment pas de raison valable de faire du raw PCM sur NES.
Et d'ailleurs faut pas hesiter a utiliser des tables avec une gamme encore plus ample. J'ai meme tester avec une table vraiment extreme, c'est a dire pousser au max (facteur x2, ce qui donne vraiment un panel complet de pente) -96,-64,-32,-16,-8,-4,-2,-1,0,+1,+2,+4,+8,+16,+32,+64 sur la version 8bit du sample (8bit j'imagine que c'est ce que tu utilises comme sample sur MD?) et ca rend encore mieux que la table que t'utilise mais le sample de Keziah a vraiment beaucoup d'harmonique a haute frequence.
J'ai d'ailleurs remarqué de grosse difference dans l'amplitude des delta selon le fichier wav/flac. Je sais pas si c'est parce que les samples wav ou flac lossless qu'on récupere sur le web ne le sont pas vraiment et viennent d'une source mp3 mais en dehors du sample que j'ai rippé sur un vieux CD (et la on est a peu pret sure que c'est du lossless et pas du MP3) les autres sont bien moins riche, les amplitudes delta n'ont rien a voir avec mon sample de Keziah. je me demande si y a pas de la compression qui a ecraser tout ca (y a pas mal de sample aussi ou le volume est pas du tout optimal, sur des resolutions 16 ou 24bit ca n'a pas vraiment d'importance mais en 8bit faut penser a amplifier le signal au max pour qu'il exploite toute la gamme deja limité sinon tu perd beaucoup en résolution)
L'idéal je pense c'est de faire une mesure sur le sample au moment ou tu produit les datas (par exemple trouver la valeur de delta qui couvre 99.9% des samples et s'en servir comme referent de l'amplitude max de ta table) et d'inclure ca avec le sample comme un metadata qui indique la table a utiliser pour ce sample. la table peut d'ailleurs etre asymétrique avec un facteur plus elevé du coté positif pour compenser le nombre de valeur et avoir moins de difference d'amplitude entre les 2.
En gros je pense que un bon DPCM 4bit bien reglé c'est bien suffisant pour du 8bit et encore plus pour du 7bit.

- l'ADPCM je suis mitigé. le DPCM marche tellement bien dans mon cas que c'est tres difficile de gagné quelque chose et faire varier les tables si tu le fait pas bien tu peux vite perdre plus que tu gagne et c'est pas facile de trouver la bonne methode a moins d'etre expert en signal. Globalement je dirais que l'effort n'en vaut pas la chandelle surtout sur NES pour du 7bit (en fait l'ADPCM c'est vraiment intéressant pour du 16bit je pense).
Mais j'ai quand meme tester different truc (et toujours avec des tables exponentiel maintenant). Faire de l'ADPCM en fonction du precedent delta ca m'a pas super convaincu, j'ai vraiment l'impression qu'il faut ajouter de l'inertie pour que ce soit intéressant, pas réagir immédiatement a chaque sample (trop chaotique) mais plutot réagir a la tendance de la sequence en court (plus calme ou intense en haute frequence). Par exemple utiliser un compteur 256 (un octet) qu'on incremente selon les delta precedents (un truc de ce genre +8,+1,+1,+1,0,0,-1,-1,-1,-1,-1,0,0,+1,+1,+8 ) et ensuite juste combiner le nibble MSB avec le prochain delta pour pointer la table 2D de delta (16x16). Ca permet une certaine inertie (avec quand meme des acceleration pour monter dans la table quand t'as des delta saturé mais une descente plus lente) et de s'adapter a la sequence.

- Par contre j'ai testé aussi un truc encore plus basique qui est de faire de l'ADPCM en fonction de la position absolu du sample précédant. C'est super pratique car t'as juste a faire un AND %11110000 sur la valeur du sample precedent et un OR avec le delta suivant pour avoir ton pointeur sur ta table 2D de delta. Et ca permet de faire varier la table selon la position absolu en decoupant l'espace en 16 bandes horizontal avec chacune leur table. (et la faut des tables asymetrique comme celles que t'as evoqué)
Alors faut pas trop faire varier les tables (a part tout en haut ou tout en bas car la t'es certain de pas avoir besoin d'une table avec une amplitude qui dépasse les limites) car les harmonique a haute frequence y en a partout mais statistiquement quand t'es dans la partie inferieur par exemple y a plus de chance que les delta positif soit superieur en moyenne aux delta negatif (sinon tu remonterais jamais). Donc on peut jouer un peu a la marge sur l'asymetrie des tables et comme ca coute rien en ressource. Je peux d'ailleurs le faire a 44khz finalement (et meme a 48khz) alors que j'avais dit reserver l'ADPCM au 22khz.

- Je me suis amusé aussi a tester ces samples en DMC donc en utilisant la fonction hardware de la NES (donc du DPCM 1bit en resolution 6bit). C'est pas plus simple que de le faire en software car y a plus de truc a paramétrer et faut prendre en charge les interruption du DMC mais justement c'etait intéressant aussi a faire comme exercice (d'autant que les interruptions DMC peuvent servir de facon detourner comme timer). Alors la qualité est vraiment horrible mais on arrive encore a reconnaitre et puis surtout ca consome moins de 1% du CPU.

- J'ai tester aussi la configuration mapper UxROM, le vieux mapper des premiers jeux. Il a l'avantage que certain emulateur (comme Fceux) accepte qu'on puisse gérer 255 banks alors qu'a l'epoque c'etait 16 max. Ce qui fait 4Mo de PRG-ROM. couplé avec le DPCM ca me permet de mettre un morceau quasi complet en 44khz, soit plus de 3mn (au lieu de 24 seconde sur la version précedante en PCM que j'avais posté). Mais c'est juste pour l'emulation. Et ca m'a permis d'apprendre aussi sur ce mapper (et la gestion des bus conflict). J'ai d'ailleurs un peu touché au MMC1 aussi et j'ai pensé a toi car le bank switching du MMC1 se fait en chargeant un registre en serie bit par bit  
Chaque mapper est different dans sa facon de gérer le bank switching.

- J'aimerais bien tester aussi avec un delta 3bit. 4bit c'est presque too much pour une resolution 7bit (c'est bien si on veut la qualité max quasi equivalente a du raw, c'est d'ailleurs ce que je voulais) et 2bit on se retrouve avec des problematiques proche du DMC (plus on reduit le delta plus on augmente l'asymetrie entre positif et negatif). En 3bit 22khz en ADPCM complet y a peut etre quelque chose a faire sur NES pour faire un mode economique (ca fait juste le double d'un sample DMC) mais avec une qualité qui soit je pense tout autre que celle du DMC. Alors c'est pas pratique le 3bit mais ne passant par des bitplan pourquoi pas.
Mais je pense que je vais mettre ca de coté , je voudrais passer a autre chose (et terminer plutot sur un ROM hack)


Quelques ROMs test:

- La version ADPCM 44khz du sample de Keziah Jones sur une ROM UxROM de 4Mo
https://drive.google.com/open?id=0B399kteofpYuSlFTVkxCd2FOaFk
a comparer avec la version PCM raw précédente. Pour moi pas de difference de qualité.

- La meme chose mais en version plus courte compatible everdrive (MMC5 512ko + 512ko)  quand meme plus longue que la version PCM grace a la compression.
https://drive.google.com/open?id=0B399kteofpYuSFdxczhIeTJxTDA

- La version DMC pour entendre ce que ca donne avec la fonction hardware.
https://drive.google.com/open?id=0B399kteofpYuTmxlM1dFZW9tVTQ
C'est sur que c'est pas comparable avec ma version software.

- Et un autre sample en DMC (un monologue)
https://drive.google.com/open?id=0B399kteofpYuV3A1UERlY19LeEk

[Invité]

Tu arrives à quoi à peut près en utilisation CPU pour les versions soft ??
Ca a l'air vraiment pas mal comme solution .

[upsilandre]

Si je compte bien ca donne 30.5 cycles par samples en DPCM (un sample a 30 et un autre a 31) et 38.5 cycles en ADPCM version basique (mais superflu ici je pense, c'etait pour le fun) et on doit pouvoir gagner encore un cycle en mettant la boucle en RAM (mais ca serait too much). en 44khz tu peux rien faire d'autre. Dans tout les cas c'est pas fait pour du in-game meme a basse frequence. In-game seul la solution du canal DMC est viable sur NES (y a une bidouille qui peut marcher ingame en utilisant le DMC sur des boucle tres courte de seulement 8 samples, le minimum, et d'utiliser l'irq du DMC pour inserer un sample raw tout les 8 samples DMC, ca doit tourner autour de 10% du cpu dans ce cas).

Mais je fais rien de spécial. C'est surtout la qualité du sample original qui fait beaucoup je pense.
Je voulais surtout avoir sous la main un bon exemple de sampling audio sur NES. Jusqu'a maintenant je citais toujours les memes exemples qu'on trouve sur Youtube

Celui la:
https://www.youtube.com/watch?v=v0dBXuZtbos


Mais en testant la ROM je me suis rendu compte que c'est pas du 16khz comme indiqué dans la description mais du 44khz et que pour du 44khz qui plus est en raw PCM (ce que je trouve etre du gachie) la qualité du sample est pas parfaite et ca vient du sample originel a priori (j'ai fais des mesure dessus et les amplitudes des delta son beaucoup plus faible que mon sample de Keziah, ce qui d'ailleurs rend d'autant plus inutile de le faire en raw pcm).
En plus il a voulu gérer le bus conflict du mapper UxROM mais s'est completement planté dans sa table du coup ca ne fonctionne pas sur Fceux par exemple (qui par défaut simule le bus conflict), d'ailleurs j'ai corrigé sa ROM.


et l'autre c'est celle la
https://youtu.be/Co1gnibPeJQ


Mais en testant la ROM je me suis rendu compte que c'est seulement du 14.7khz (ca passe plutot bien pour cette frequence) et encore une fois en raw PCM. L'idée ici etait plutot de faire des petits effet grpahique en meme temps mais du coup c'est pas non plus une demo qui pousse au mieux la qualité.
Je voulais avoir sous la main une demo qui pousse au max la qualité mais sans abus non plus (pas du raw inutile ou du 200khz).
J'ai quand meme envie de tester en ADPCM 3bit 22khz, je suis sure qu'on peut obtenir un truc potable (et au moins l'ADPCM serait peut etre plus intéressant a tester en 3bit)

[Invité]

Ouai c'est pas mal, et c'est peu de cycles finalement, bon à haute fréquence ça va en bouffer bcp, mais y'a moyen de faire un truc pas mal .

[Stef]

Upsilandre>
Vraiment excellent tous ces tests et cette analyse que tu as pu faire, c'est très instructif et très utile aussi pour mes futurs choix
Du coup ça remet en cause mon passage du DPCM en ADPCM pour mon driver MD. Sinon c'est effectivement du PCM 8 bits (tu peux accéder au 9eme bits du DAC mais c'est beaucoup moins pratique que du 8 bits) et je trouve que le DPCM à 22 Khz produit déjà un assez bon résultat.
Après il y a quand même des choses à prendre en compte pour vraiment valider telle ou telle méthode de compression. Par exemple ici tu testes avec une musique qui contient beaucoup de fort deltas en général, ce qui est bien pour éprouver le codec mais malgré tout je pense qu'il te faudrait plusieurs échantillons pour tester correctement (les samples avec des deltas plus faibles et plus précis sont interessants à tester aussi, genre un thème classique).

Sinon je pense que la table exponentielle vient assez logiquement, malgré tout un delta de +64 sur un sample c'est vraiment énorme je trouve. Et c'est là qu'il y a un autre facteur à prendre en compte : le sampling rate. Automatiquement en augmentant le sampling rate tu as de bonnes chances de réduire le delta max nécessaire (car tu as moins de très hautes fréquences avec une forte dynamique). C'est d'ailleurs pour ça que j'ai choisi de faire du DPCM à 22 Khz, en dessous de 22 Khz j'avais peur que les pertes soient trop importantes... Avec du 44 Khz je dirais que tu réduis encore plus les deltas max nécessaires du coup tu peux ajuster ta table pour permettre plus de précision sur les faibles deltas.

Pour ce qui est du ADPCM 3 bits, ça me parait effectivement un bon compromis. J'ai déjà tenté le ADPCM 2 bits (pour des raisons de pratique : 4 samples dans 1 octet là ou tu es obligé de traiter 8 samples sur 3 octets avec du ADPCM 3 bits) et je n'étais pas satisfait de la qualité obtenue (trop de perte)... Surement que le 3 bits (pour un base 8 bits) est un bon équilibre, dommage que 3 bits ça soit moins pratique à manipuler :-/

[upsilandre]

Upsilandre>
Sinon je pense que la table exponentielle vient assez logiquement, malgré tout un delta de +64 sur un sample c'est vraiment énorme je trouve. Et c'est là qu'il y a un autre facteur à prendre en compte : le sampling rate. Automatiquement en augmentant le sampling rate tu as de bonnes chances de réduire le delta max nécessaire (car tu as moins de très hautes fréquences avec une forte dynamique).

Sur le sample de Keziah a 44khz j'ai deja des delta jusqu'a +125. et quand je cherche le delta qui permet de couvrir 99.9% des samples (c'est la regle que je m'etais fixé) ca me donne +62. Mais tu devrais quand meme tester ce genre de table max avec une evolution x2. Je pense que tu sera peut etre surpris de voir comment ca marche bien si t'a jamais essayé. Ca te donne vraiment un panel tres complet de pente et tu garde toujours de toute facon les pentes douce (+1, +2) ce qui permet de toujours exploiter la resolution finalement.
Mais c'est claire que ca change beaucoup d'une musique a l'autre c'est pour ca que plutot que de s'emmerder avec l'ADPCM je conseille plutot d'integrer a l'outil qui transforme le sample en data un systeme de mesure et de selection d'une table fixe sur mesure et integré au metadata du sample. Que chaque sample debarque avec sa table. Faire plutot le boulot en amont, je pense que c'est encore plus efficace ici et sans consomer de ressource supplementaire pour la machine.

C'est d'ailleurs pour ça que j'ai choisi de faire du DPCM à 22 Khz, en dessous de 22 Khz j'avais peur que les pertes soient trop importantes...

De ce que j'ai pu tester y a peu de difference entre 44khz et 22khz par contre entre 22khz et 11khz y a une grosse difference. C'est pour ca que j'aimerais bien faire un mode 22khz, c'est un bon compromis.

Pour ce qui est du ADPCM 3 bits, ça me parait effectivement un bon compromis. J'ai déjà tenté le ADPCM 2 bits (pour des raisons de pratique : 4 samples dans 1 octet là ou tu es obligé de traiter 8 samples sur 3 octets avec du ADPCM 3 bits) et je n'étais pas satisfait de la qualité obtenue (trop de perte)... Surement que le 3 bits (pour un base 8 bits) est un bon équilibre, dommage que 3 bits ça soit moins pratique à manipuler :-/

C'est vrai que c'est chiant, et justement j'etais en train de me dire par exemple que tu pouvais pas utiliser tout les octets d'une page 256 a moins de se compliqué beaucoup la vie, y a au moins un octet de perdu et du coup dans l'idée que j'evoquais juste avant pourquoi pas y mettre des metadata.
J'aime bien l'idée de faire du DPCM mais que la table fixe puisse s'adapter a chaque portion de sample selon ses metadata.
Mon idée ca serait de decomposer chaque page de 256 octets qui compose le sample de cette facon:
- 84 triplet qui contiennent chacun 8 delta 3bit
- 4 octet qui contiennent chacun les 5bit MSB (a combiner en OR avec les data 3bit) qui pour chaque sequence de 21 triplet permet de pointer une table de delta parmis 32 prédéfinis.

Donc chaque sequence de 168 samples (donc des sequences tres courtes) aurait sa propre table selectioner sur mesure en amont par l'outil qui produit les data.
l'idée serait de prédéfinir 32 tables 3bit fixe avec differente amplitude (et asymetrie entre negatif et positif) et de faire précomputer chaque sequence de 168 samples par l'outils en donnant un score pour chacune des 32 tables pour lui laisser selectionner la table qui a le meilleur score (reste a definir la facon de calculer le score, selon l'erreur de position absolu des sample? ou de la pente? comment ponderer les gros ecart par rapport aux autres?) et integer ce choix dans les metadata. Ca couterait quasiment rien en data supplementaire ni en ressource CPU (surtout si tu divise plutot en 85 triplet et seulement 1 octets de metadata pour l'integralité de la page soit 672 samples) et je suis certain d'obtenir mieux qu'avec de l'ADPCM tres hasardeux. (Ca reste une forme d'ADPCM mais précalculé donc avec un resultat plus prévisible et certain)

Mais bon la complexité de ces questions est infini, faudrait etre un expert du traitement de signal pour bien faire les choses.  A defaut faut bricoler.

[Stef]

En fait ce que tu décris comme compression ça ressemble beaucoup à des compressions ADPCM existantes (qui fonctionnent par chunk). D'ailleurs le format BRR du SPC700 de la Snes s'inspire un peu de ça aussi sauf que ça travaille sur des blocs de 9 octets pour 16 samples (4bit --> 16 bit).
Perso je pense que c'est un bon compromis : une table pour 168 samples... En fait une granularité plus fine serait probablement préférable (1 table pour 48 ou 96 samples par exemple) mais ça devient tout de suite beaucoup plus compliqué à découper.
Pour le calcul du score, je sais que moi je fais en fonction de l'écart avec la position absolu mais réellement il faudrait quelque chose de plus complexe, en prenant en compte la différence fréquentielle et la dynamique. Mais bon là encore ça devient tout de suite bien plus compliqué ^^ Et les résultats que j'avais obtenus juste avec l'écart sur la position absolu me donnaient satisfaction

Sinon tu dis que c'est du bricolage mais réellement quand tu regardes les codecs ADPCM existants tu t'apercevras que c'est assez proche de ce que tu décris quand même Surtout quand on est assez limité en ressource CPU comme ici pour assurer la décompression...

J'ai déjà pensé à un codec plus évolué pour avoir un meilleur taux de compression et qui tienne toujours sur un Z80, un truc à base de DCT (Discrete Cosinus Transform) avec des LUT dans tout les sens... mais bon là je pense que j'atteins les limites de mes connaissances tant en traitement du signal qu'en math :p quand j'aurai le temps je m'y pencherai un peu plus mais je ne suis pas sur d'arriver à quelque chose de concluant

[upsilandre]

En fait ce que tu décris comme compression ça ressemble beaucoup à des compressions ADPCM existantes (qui fonctionnent par chunk). D'ailleurs le format BRR du SPC700 de la Snes s'inspire un peu de ça aussi sauf que ça travaille sur des blocs de 9 octets pour 16 samples (4bit --> 16 bit).
Perso je pense que c'est un bon compromis : une table pour 168 samples... En fait une granularité plus fine serait probablement préférable (1 table pour 48 ou 96 samples par exemple) mais ça devient tout de suite beaucoup plus compliqué à découper.

En reflechissant je pensais a un découpage 3bit plus logique et optimal que ce que j'ai dit. Pas la peine de mettre a part le pointeur 5bit de la table associé a la sequence.
La sequence pourrait demarrer par un octet qui contient directement un pointeur deja pret a l'emploie (5 bit msb de la table + les 3bit lsb du delta) ce qui laisse du temps sur ce premier sample pour récuperer les 5bit msb de la table (AND %11111000) qu'on appliquera ensuite (OR) a chaque data 3bit des triplet d'octet suivant (paquet de 8 samples). Ca permet de gacher aucun bit et d'avoir une répartition plutot intéressant des cycle cpu entre les samples.
Pour utiliser la page de facon otpimal ca laisse 4 configurations:
Une table pour 681 samples = 3.01 bit par sample
Une table pour 169 samples = 3.03 bit par sample
Une table pour 41 samples = 3.12 bit par sample
Une table pour 9 samples = 3.56 bit par sample

meme en 4bit cette methode ADPCM précalculé c'est certain que ca serait mieux que celle que j'ai utilisé. Et c'est meme encore plus simple en ressource (notamment si tu te contente d'une table par page, ca coute rien) donc je suis bien partie pour refaire aussi ma version 44khz.
Je me demande meme si je peux pas faire la version 3.56bit a 44khz.

Pour le calcul du score, je sais que moi je fais en fonction de l'écart avec la position absolu mais réellement il faudrait quelque chose de plus complexe, en prenant en compte la différence fréquentielle et la dynamique. Mais bon là encore ça devient tout de suite bien plus compliqué ^^ Et les résultats que j'avais obtenus juste avec l'écart sur la position absolu me donnaient satisfaction

Oui je pense que je me contenterais de ca. Ca suffira pour faire un choix relativement pertinent entre les 32 tables.

[Stef]

En reflechissant je pensais a un découpage 3bit plus logique et optimal que ce que j'ai dit. Pas la peine de mettre a part le pointeur 5bit de la table associé a la sequence.
La sequence pourrait demarrer par un octet qui contient directement un pointeur deja pret a l'emploie (5 bit msb de la table + les 3bit lsb du delta) ce qui laisse du temps sur ce premier sample pour récuperer les 5bit msb de la table (AND %11111000) qu'on appliquera ensuite (OR) a chaque data 3bit des triplet d'octet suivant (paquet de 8 samples). Ca permet de gacher aucun bit et d'avoir une répartition plutot intéressant des cycle cpu entre les samples.
Pour utiliser la page de facon otpimal ca laisse 4 configurations:
Une table pour 681 samples = 3.01 bit par sample
Une table pour 169 samples = 3.03 bit par sample
Une table pour 41 samples = 3.12 bit par sample
Une table pour 9 samples = 3.56 bit par sample

meme en 4bit cette methode ADPCM précalculé c'est certain que ca serait mieux que celle que j'ai utilisé. Et c'est meme encore plus simple en ressource (notamment si tu te contente d'une table par page, ca coute rien) donc je suis bien partie pour refaire aussi ma version 44khz.
Je me demande meme si je peux pas faire la version 3.56bit a 44khz.

Je trouve que 3.56 bit par sample, le compression commence à être moins interessante car on se rapproche du 4 bit / sample qui même en pur DPCM donne déjà une qualité correcte. J'opterai pour le 3.12 bit ce qui donne un ratio de compression un poil supérieur (2.5) là où tu as seulement un taux de compression de 2.24 avec 3.56 bit.
Enfin encore une fois, tout ça se test pour voir si dans les faits, la différence de qualité vaut le coup :)

[upsilandre]

Ouai le 3.56 bit je le garde juste pour remplacer ma version 44khz 4bit. Je suis curieux de voir ce que ca peut donner. En tout cas malgres le découpage 3bit et la table par paquet de 9 samples, au niveau du code ca passe sans probleme a 44khz et meme a 48khz.
pour la version 22khz plutot 3.12 car le bute c'est de faire economique.

[Stef]

Du ADPCM 3.56 bit à 48 Khz sur le 6502, bien joué
Faudrait que je garde l'idée du 3.12 bit de côté, j'aimerai bien tenté un ADPCM 3.12 bit @16 Khz et sur 3 channels pour le driver XGM v2 :p

[upsilandre]

Bon ca y est j'ai fais mes test en ADPCM 3.56bit et ca marche super bien. Meme mieux encore que mon precedent ADPCM 4bit simpliste. la forme de la wave est vraiment tres proche du raw, quasiment pas de difference. Je suis plutot content (c'etait pas gagné avec des delta 3bit mais j'etais plutot confiant), je pense que pour la NES je vais m'arreter sur ces modes 3bit précomputé (3.56, 3.12, 3.01) et laisser de coté le 4bit. Ca fait vraiment bien le job pour le 7bit de la NES.

Je te met les 32 tables 3bit que j'utilise (généré mathematiquement), ca peut toujours servir.

Code:

[ -3, -2, -1, 0, 1, 2, 3, 4],
[-4, -2, -1, 0, 1, 2, 3, 5],
[-4, -2, -1, 0, 1, 2, 4, 6],
[-5, -3, -1, 0, 1, 3, 4, 7],
[-6, -3, -1, 0, 1, 3, 5, 8],
[-7, -3, -1, 0, 1, 3, 6, 10],
[-8, -4, -2, 0, 2, 3, 7, 12],
[-9, -4, -2, 0, 2, 4, 8, 15],
[-11, -5, -2, 0, 2, 4, 9, 18],
[-13, -5, -2, 0, 2, 5, 10, 21],
[-15, -6, -2, 0, 2, 5, 12, 25],
[-17, -7, -2, 0, 2, 6, 13, 31],
[-20, -7, -3, 0, 2, 6, 15, 37],
[-23, -8, -3, 0, 2, 7, 17, 44],
[-27, -9, -3, 0, 3, 7, 20, 53],
[-32, -10, -3, 0, 3, 8, 23, 64],

[-4, -3, -2, -1, 0, 1, 2, 3],
[-5, -3, -2, -1, 0, 1, 2, 4],
[-6, -4, -2, -1, 0, 1, 2, 4],
[-7, -4, -3, -1, 0, 1, 3, 5],
[-8, -5, -3, -1, 0, 1, 3, 6],
[-10, -6, -3, -1, 0, 1, 3, 7],
[-12, -7, -3, -2, 0, 2, 4, 8],
[-15, -8, -4, -2, 0, 2, 4, 9],
[-18, -9, -4, -2, 0, 2, 5, 11],
[-21, -10, -5, -2, 0, 2, 5, 13],
[-25, -12, -5, -2, 0, 2, 6, 15],
[-31, -13, -6, -2, 0, 2, 7, 17],
[-37, -15, -6, -2, 0, 3, 7, 20],
[-44, -17, -7, -2, 0, 3, 8, 23],
[-53, -20, -7, -3, 0, 3, 9, 27],
[-64, -23, -8, -3, 0, 3, 10, 32]]

Pour résumé y a 16 tables 3bit qui vont d'une amplitude [-3,+4] a [-32,+64] avec une évolution exponentiel et ensuite c'est les meme 16 tables mais en inversant l’asymétrie entre negatif et positif ( donc [-4,+3] a [-64,+32]) comme ca pas d'avantages pour l'un ou l'autre, ca pioche celle qui correspond le mieux au besoin.

bon moi c'est des tables adapté pour du 7bit donc les tables qui vont jusqu'a 64 d'amplitude ca correspondrait a un delta 128 pour toi, donc une amplitude qui peut te paraitre tres forte mais sur le morceau de Keziah (mon stress test) c'est des tables qui sont quand meme selectionner (et donc ou y a le moins d'erreur en position absolu) sur plusieurs milliers de chunk (4500 fois) donc loin d'etre inutile, et je suis toujours a 44khz. J'ai générer des stats et au final les 32 tables sont bien exploité et de facon relativement equitable (a part les toutes dernieres mais meme la plus forte est utilisé "seulement" 10 fois moins que la moyenne). Apres sur d'autre morceau les dernieres tables serait moins utilisé c'est certain mais le bute c'est d'avoir quelque chose qui s'adapte a tous les morceau.

Ensuite le format du paquet de 4 octets qui contient 9 samples est sous cette forme:
ttttt111 44333222 76665554 99988877
t = les bits qui servent a indexer la table utilisé pour les 9 samples
Les nombres associé aux bit correspondent au numeros du sample dans l'ordre chronologique.

J'ai pas encore testé l’implémentation sur NES mais j'avais deja fait quasiment tout le code, reste plus grand chose pour tester sur ROM tantot (donc toujours a 44khz, ensuite faudrait que je teste la version 3.12bit a 22khz).

[upsilandre]

Par contre en python (donc language interprété et pas compilé) ca me prend quand meme environ 8 minutes pour computer 1 minute de sample 44khz (tester les 32 tables sur chaque paquet de 9 samples pour selectionner la plus adapté).
Evidement c'est pas tres grave vu que t'as juste a le faire une fois mais ca montre qu'il faut quand meme faire gaffe, ca monte vite. Bon évidement je pourais optimiser le code mais c'est pas trop le bute du python.Je reserve ca pour la partie 6502

[Stef]

Merci Upsilandre, tes tables sont très équilibrées je comprends que ça fonctionne bien en 3.56 bits :) Je suis étonné que le taux d'utilisation des différentes tables soit si équilibré sur ta musique Keziah de test, elle est vraiment adaptée à ce genre de benchmark
Sinon je serais curieux de voir ce que donne le 3.12 bits à 22 Khz, c'est un format qui m'interesse bien mais je crains que les pertes soient bien plus importantes quand même...

Sinon oui le compression peut vite prendre des ressources quand tu fais une approche "brute force" (j'imagine que c'est ce que tu fais pour chaque chunk de sample), je code mes outils en java, heureusement c'est un langage assez performant car j'ai dejà du faire des algos bien bien long aussi (pour de la compression également).

[upsilandre]

C'est en discutant avec toi sur le topic que j'ai fais evoluer le truc, c'est ca qui est cool.
Bon aujourd'hui j'ai enchainé l’implémentation de cette ADPCM 3.56bit dans 3 versions de ROMs differentes

une version 44khz MMC5 1Mo (donc version courte compatible avec tout): https://drive.google.com/open?id=0B399kteofpYuRFpfM1dfZkNBZHc

une version longue UROM 4Mo surtout pour moi car c'est pas compatible avec grand chose.

et une version 22khz MMC5 1Mo qui passe encore tres bien meme si je sent la difference (notemment sur la voix): https://drive.google.com/open?id=0B399kteofpYuVVZGOEZxRmEwV0E

Par contre j'ai la flemme de tester le 3.12bit. Je pense que je le ferais si un jour j'en ai besoin. La je voudrais plutot tenter un ROM hack et mettre ca https://www.emuparadise.me/soundtracks/highquality/download/Rockman1-6/FLAC/04_Dr.Wily_1_(Rockman2)_mix/3382 sur l'ecran titre de Megaman1. Ca serait rigolo.

[Stef]

C'est en discutant avec toi sur le topic que j'ai fais evoluer le truc, c'est ca qui est cool.
Bon aujourd'hui j'ai enchainé l’implémentation de cette ADPCM 3.56bit dans 3 versions de ROMs differentes

une version 44khz MMC5 1Mo (donc version courte compatible avec tout): https://drive.google.com/open?id=0B399kteofpYuRFpfM1dfZkNBZHc

une version longue UROM 4Mo surtout pour moi car c'est pas compatible avec grand chose.

et une version 22khz MMC5 1Mo qui passe encore tres bien meme si je sent la difference (notemment sur la voix): https://drive.google.com/open?id=0B399kteofpYuVVZGOEZxRmEwV0E

Par contre j'ai la flemme de tester le 3.12bit. Je pense que je le ferais si un jour j'en ai besoin. La je voudrais plutot tenter un ROM hack et mettre ca https://www.emuparadise.me/soundtracks/highquality/download/Rockman1-6/FLAC/04_Dr.Wily_1_(Rockman2)_mix/3382 sur l'ecran titre de Megaman1. Ca serait rigolo.

Franchement la qualité entre les 2 est vraiment proche je trouve, sous Nestopia ça rend vraiment super
Ca serait génial si tu pouvais appliquer le hack dont du parle pour MM1, ça en jetterait
As tu pu tester sur une vraie NES ? je serais curieux de savoir si ça rend aussi bien que sur Nestopia (sur RockNES ça sonne pas terrible par exemple).

[upsilandre]

Y a que Vincent qui a testé sur une vrai NES.
J'aimerais bien m'en occuper mais j'ai la flemme de chercher qu'elle NES il me faudrait (je voudrais une NES qui prend les jeux jap/us 60hz et j'aimerais pouvoir la faire fonctionner sur mon plasma directement) et ou la trouver

[vincent2105]

Je testerai ca sur NES dimanche je pense.  
Sous Fceux et si on voulait pinailler, je dirais qu'on perçoit un bruit de "souffle" continu en 22 Khz. (on devient difficile après la version 44 Khz :p)
En tous cas c'est excellent tout ça ! Chapeau upsilandre 

[vincent2105]

Bon, je me suis remis à coder un peu depuis 3 jours.
Mon objectif était d'écrire une routine de détection de background / priorité du sprite.
Je reconnais que le tout est brouillon, mais c'est un premier jet visant à entretenir la motivation.
Par la suite, je vais créér une map (ici il ne s'agit que d'un unique écran, et le sprite n'est pas animé), et m'amuser avec le bankswitch de CHR_ROM pour animer tout le background.

ROM : https://drive.google.com/open?id=0B0HKOrG7iEpfRHctZkF2aWhWblU

[upsilandre]

voila c'est ce qu'on aime, des screenshots et des ROMs.
s'attaquer a l'occlusion sur NES c'est un exercice intéressant. C'est tellement facile a faire sur SMS et compliqué sur NES. Ca me rappele Ys sur la version SMS tu peux effectivement passer derriere les arbres et sur la version NES ils ont enlevé cette possibilités (et reduit la taille des arbres pour que ce soit pas trop génant). Sur SMS c'est facile, suffit de mettre les bon attribut de tile