[2.2.4] Impossible de faire fonctionner winapi.inc (concerne GetSystemMetrics)

Version imprimable

Voir 40 message(s) de cette discussion en une page

28/12/2022, 08h30
Jipété

Bonjour,

Citation:

Envoyé par bb84000

C'est ICI

Tu as édité ton post, hier, après mon passage ?
Hier quand j'ai suivi le lien, j'ai atterri sur le bon post, aujourd'hui ça ne fonctionne plus, j'atterris ailleurs ! :koi:

Ce matin j'atterris sur le post #20 quand le tien serait le #19, et le 11905770 tel qu'indiqué par le navigateur quand on met la souris sur le lien est le #132

Je ne sais pas ce qui se passe...
28/12/2022, 09h47
bb84000

Bonjour Jipété !

Je ne pense pas avoir édité mon post. Mais c'est bien sur le tien (132) que je pointe, puisque tu as utilisé (et amélioré) le code donné sur mon précédent message !

Ceci étant, je ne parviens toujours pas à utiliser le code développé sous Windows avec Lazarus LInux. Je vais prochainement ouvrir un nouveau sujet à ce propos.

bb84000

Bonsoir,

et bonne année bonne santé et bons codes !

De mon côté, je suis en train de me perdre, je vous raconte : presque au bout du tunnel, je me suis souvenu qu'un projet récemment récupéré sur le web n'était pas content à l'ouverture de certains .wav générés avec des codes trouvés ici et là, et comme j'estimais que ça faisait désordre, j'ai essayé d'y voir clair.
J'aurais mieux fait d'aller me noyer, tiens !

Parce qu'au bout du compte, non seulement on trouve des logiciels branquignols, mais les fichiers créés ne sont pas en reste, le mystère étant que les fichiers refusés par Wavexplorer sont quand même acceptés par Audacity et Audacious (un player Linux).

Au final, je me suis dit qu'il me fallait des fichiers .Wav de test et, si on peut en trouver des millions quand on travaille avec l'image, j'ai dû mal m'y prendre mais je n'ai quasiment rien trouvé concernant les .wav ! Est-ce qu'en faire générer par Audacity créera des fichiers valides ?, that's the question... :calim2:

Si quelqu'un sait où en trouver, sa réponse est impatiemment attendue, et grand merci par avance.

Dans l'attente, un coup d'œil sur l'intérieur de certains de ces fichiers, qui sont tous stéréo, en 44100 Hz pour le SampleRate, 16 pour le BitsPerSample, 176400 pour le ByteRate et 4 pour le BlockAlign, les 3 premiers durent 5 secondes et les 2 autres 2 secondes, données aléatoires remontées par Wavexplorer :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Size of data block (bytes) : 14112000 Total number of samples : 7056000 Number of samples per channel : 3528000 Duration (s) : 80.0 <<< ! 5 secondes dans Audacious Size of data block (bytes) : 880800 Total number of samples : 440400 Number of samples per channel : 220200 Size of data block (bytes) : 882000 Total number of samples : 441000 Number of samples per channel : 220500 Size of data block (bytes) : 352800 Total number of samples : 176400 Number of samples per channel : 88200 Size of data block (bytes) : 352812 Total number of samples : 176406 Number of samples per channel : 88203
Enfin, j'aurais besoin d'un avis, suite à la lecture de ce bout de code de Wavexplorer :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 function TWavFile.GetSampleFormat: TWavSampleFormat; begin case FHeader.AudioFormat of 1: case FHeader.BitsPerSample of 8: Result := wsfInt8; 16: Result := wsfInt16; 24: Result := wsfInt24; 32: Result := wsfInt32; 64: Result := wsfInt64; else raise EWavFile.Create('Bits per sample not supported'); end; 3: case FHeader.BitsPerSample of // 3 ???????????? Audacity génère des fichiers en 32bits flottants avec 1 pour AudioFormat et j'ai trouvé // AudioFormat (2 octets) : Format du stockage dans le fichier (1: PCM entier, 3: PCM flottant, 65534: WAVE_FORMAT_EXTENSIBLE) // là : https://fr.wikipedia.org/wiki/Waveform_Audio_File_Format // mais je n'ai rien trouvé de plus... 32: Result := wsfFloat32; 64: Result := wsfFloat64; else raise EWavFile.Create('Bits per sample not supported'); end; else raise EWavFile.Create('Audio format not supported'); end; end;
Une idée sur ce point ?

03/01/2023, 08h09
bb84000

Bonjour, et meilleurs voeux à tous !

Citation:

Envoyé par Jipété

Une idée sur ce point ?

Les valeurs possibles (?) de AudioFormat (wFormatTag pour Microsoft) se trouvent dans le fichier mmreg.h (version de Microsoft 1998) , et elles sont utilisées dans le header "extended" en plus de WAVE_FORMAT_PCM (=1) qui était défini dans le header original. je n'ai pas trouvé de version plus récente...

bb84000

Bonjour Bernard,

Merci pour ton lien, mais qui ne m'a apporté aucune information technique... Du Crosoft pur et dur...

Et dans un autre environnement, ce qui suit concerne Linux only.
Alors, j'adooooooooooore l'informatique de maintenant ! Dans man sox je trouve, tout à la fin,
Code:

1 2 3 SEE ALSO soxi(1), soxformat(7), libsox(3) audacity(1), gnuplot(1), octave(1), wget(1)
et comme je suis curieux, je creuse, mais mal m'en a pris :
Code:

1 2 3 4 $ man libsox Aucune entrée de manuel pour libsox $ man 3 libsox Aucune entrée de manuel pour libsox en section 3
Quelle déception !
Pas pour le manque d'information technique, non, mais bien plutôt pour le foutage de gueule, quoi !

Heureusement il y a aussi ça : SoX scripting examples at http://sox.sourceforge.net/Docs/Scripts, où l'on peut lire
Code:

1 2 3 4 5 6 7 8 9 Sample scripts using SoX. Files ending in '.sh' are Unix /bin/sh scripts; files ending in '.bat' are Windows cmd batch files. alert.sh - Create an alternating alert tone. (view) (download) batch-example.bat - Example of how to do batch processing with SoX on MS-Windows. (view) (download) crossfade.sh - Crossfade two audio files. (view) (download) crossfade_cat.sh - Crossfade two audio files into a single file. (view) (download) testtones.sh - Create a set of audio files that can be used to test audio equipment reproduction quality. (view) (download) voice-cleanup.sh - Trim and normalise voice recordings. (view) (download)
et vous pensez bien que mon sang n'a fait qu'un tour en lisant l'avant-dernière ligne, sauf que pour y accéder c'est un poil ardu : les liens "view" et "download" renvoient sur la même page, où l'on trouve
Code:

1 2 3 You can view a list of files or copy all the CVS repository data via rsync (the 1st command lists the files, the 2nd copies): - rsync -a a.cvs.sourceforge.net::cvsroot/sox/ - rsync -ai a.cvs.sourceforge.net::cvsroot/sox/ /my/local/dest/dir/
et je vous évite une déconvenue : les scripts se trouvent dans sox/scripts, donc la commande sera

Code:

rsync -ai a.cvs.sourceforge.net::cvsroot/sox/sox/scripts/ /my/local/dest/dir/

Le seul truc curieux, après le dl, c'est que tous les fichiers sont nommés "un_nom.sh,v*" et que l'examen du premier montre des choses dedans n'ayant rien à voir avec un script Bash mais bon, il y a aussi une partie purement script donc ça devrait aller.

C'est tout pour aujourd'hui, d'autres urgences sur le gaz m'attendent...

03/01/2023, 11h16
bb84000

Salut Jipété,

Cela ne me surprend pas qu'on ne trouve rien de vraiment pertinent dans tout ça. Et que certains paramètres des flux plantent une application ou une autre...

bb84000
05/01/2023, 19h11
Jipété

1 pièce(s) jointe(s)

Bonsoir,

les dernières nouvelles :

Concernant cette blague de man 3 libsox absent, c'est normal, d'après Debian (https://packages.debian.org/sid/amd6...x-dev/filelist) le man de ce fichier vient avec libsox-dev qui n'est pas installé chez moi, et que je n'ai pas envie d'installer car sox m'énerve un peu, sa ligne de commande est assez ardue.
Et je n'ai pas trouvé de forum pour pouvoir en discuter...

Ceux qui sont intéressés pourront regarder là https://sox.sourceforge.net/, et ils découvriront que la dernière mise à jour de cette page date de... février 2015.

Sinon, j'ai découvert une blague dans sox, lors de la génération de fichiers 32 bits en float, qui ne ressemblent pas à ceux générés par Audacity, résultat sox ne passe pas le test avec wavexplorer alors qu'audacity le réussit.
Le problème dans ce contexte est la génération d'un chunk "fact" supplémentaire avant le classique "data", et sox ne le positionne pas au même endroit qu'audacity :
Pièce jointe 631951

Ceux qui veulent tester pourront commencer avec la ligne de commande de sox pour du PCM standard (remarquez le "3" en 2^e ligne 5^e colonne dans les copies ci-dessus, d'habitude on a "1" pour le PCM standard, remarquez aussi que sox [titre "soir..."] annonce un chunksize de 12 quand audacity reste à 10) :
Ah, le "-V" c'est pour voir ce qui se passe, on peut l'omettre.

Code:

$ sox -V -r 44100 -c 2 -e signed -b 16 -n outputsigned16.wav synth 3 sine 440

ok mais saturé, alors je baisse un peu le niveau avec --norm= et mono pour bien voir en grand dans Audacity :

Code:

sox -V --norm=-0.01 -r 44100 -c 1 -e signed -b 16 -n outputMonoSigned16.wav synth 3 sine 440

résultat c'est tout bon -- le même en stéréo :

Code:

sox -V --norm=-0.01 -r 44100 -c 2 -e signed -b 16 -n outputSterSigned16.wav synth 3 sine 440

mais ces deux-là ont le chunk 'fact' ! alors que le premier ne l'a pas :koi: Lié à l'arrivée de l'otion --norm ? En la déplaçant plus loin sur la ligne,

Code:

$ sox -V -r 44100 -c 2 -e signed -b 16 -n outputsigned16.wav --norm=-0.01 synth 3 sine 440

plus de 'fact', yaisse !
En mode integer 16 bits.
Parce qu'en mode float 32 bits, bim !, le 'fact' mal placé revient.

Code:

$ sox -V -r 44100 -c 2 -e float -b 32 -n soxStereoFloat32.wav --norm=-0.01 synth 3 sine 440

Alors comme je ne me sens pas le courage de mettre mes mains tout au fond du cambouis de sox, je sens que je vais faire générer les fichiers pour tester les bargraphs par audacity et puis voilà, ça ira bien comme ça.

Juste que c'est dommage, parce qu'un outil comme sox, une fois la ligne de commande maitrisée, est quand même plus rapide et scriptable que cliquer à gauche à droite dans audacity...
09/01/2023, 19h41
Jipété

2 pièce(s) jointe(s)
Bonsoir,

des nouvelles :

d'abord, quand on voit ça et qu'on constate qu'il n'y a QUE ça
Code:

1 2 3 4 5 6 const AUDIO_CHUNK_ID_RIFF = 'RIFF'; AUDIO_CHUNK_ID_WAVE = 'WAVE'; AUDIO_CHUNK_ID_fmt = 'fmt '; AUDIO_CHUNK_ID_data = 'data'; AUDIO_FORMAT_PCM = 1;
dans .../fpcsrc/3.2.2/packages/fcl-sound/src/fpwavformat.pas, on se dit que, franchement, on ne pourra pas bosser avec FPC pour le son, genre fpc ignore complètement le subchunk fact que j'ai rencontré dans les fichiers WAVE_FORMAT_IEEE_FLOAT, et il y a d'autres tags récemment découverts :
Pièce jointe 632175
Pièce jointe 632176
Les 2 derniers sont des classiques Signed16Bits, à comparer avec les autres, où le préfixe "aud" signifie qu'ils viennent d'Audacity

Bref, on n'est pas rendus, surtout quand on lit ce genre de chose trouvée là, un peu épouvantable à lire, ça m'a pris un temps dément, mais c'est tellement intéressant, allez, juste un extrait :

Citation:

What Every Computer Scientist Should Know About Floating-Point Arithmetic

Despite these examples, there are useful optimizations that can be done on floating-point code. First of all, there are algebraic identities that are valid for floating-point numbers. Some examples in IEEE arithmetic are (x et y sont des variables, le petit x c'est la multiplication -- jpt) x + y = y + x, 2 × x = x + x, 1 × x = x, and 0.5 × x = x/2.
However, even these simple identities can fail on a few machines such as CDC and Cray supercomputers.

Terrifiante, cette dernière ligne, non ?
Et allez jusqu'au bout de ce paragraphe, assez flippant :
Citation:
Systems Aspects
The design of almost every aspect of a computer system requires knowledge about floating-point. Computer architectures usually have floating-point instructions, compilers must generate those floating-point instructions, and the operating system must decide what to do when exception conditions are raised for those floating-point instructions. Computer system designers rarely get guidance from numerical analysis texts, which are typically aimed at users and writers of software, not at computer designers.
As an example of how plausible design decisions can lead to unexpected behavior, consider the following BASIC program.

Code:

1 2 3 q = 3.0/7.0 if q = 3.0/7.0 then print "Equal": else print "Not Equal"

When compiled and run using Borland's Turbo Basic on an IBM PC, the program prints Not Equal!
Et comme en cherchant on trouve, ben je partage ça :
https://www.audiosciencereview.com/f...are-add.40409/
et ça
https://notabs.org/fpuaccuracy/index.htm
ça m'a bien intéressé.
Et là, il y a un pdf qui reprend tout ce qu'on doit savoir sur le sujet, même si ce n'est plus tout jeune, mais les bases sont bonnes.

Et pour finir, un peu de technique de code :

Citation:

Generating a sine-wave test tone
...
When you change the frequency with the current code, you'll end up with an artifact. To combat this, ...

lecture : https://guide.handmadehero.org/code/day009/
et dans la même veine : https://docs.juce.com/master/tutorial_sine_synth.html

J'en ai pour plusieurs mois, quoi, :ptdr:
:coucou:

Bonsoir Bernard, et les autres,

Citation:

Envoyé par bb84000

J'aurais bien voulu utiliser le TWavWriter natif de FPC, dans le code du "générateur" mais je n'y arrive pas. Il y a une histoire de buffer qui "exceptionne". Ça attendra quelques jours.

J'ai trouvé.

Ça a été long, compliqué, pas documenté et curieux, mais ça fonctionne, ho !, au strict minimum, mais ça permettra d'avancer pour générer facilement des fichiers de test.

Curieux car lorsque je lis un fichier avec TWavReader, il se passe ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
procedure TForm1.btnTestReaderClick(Sender: TObject);
type
  TByteArray = array of byte;
var
  Buffer: TByteArray;
  finStream: TMemoryStream;
  i, aFileSize: integer;
  af,acc,asr,abr,aba,abps: integer;
 
  function LoadFromWav(const aFilename: String; var Buffer: TByteArray):Boolean;
  var
    rTmp : TWavReader;
  begin
    Result := False;
    rTmp := TWavReader.Create;
    with rTmp do
      try
        if not LoadFromFile(aFilename) then begin // loadfromfile calls loadfromstream
          ShowMessage('Error loading '+aFileName);
          Free;
          Exit;
        end;
        // function TWavReader.ReadBuf(var Buffer; BufferSize: Integer): Integer; // for help
        i := ReadBuf(Buffer, aFileSize); // read from File to Buffer ? Yes mais pourquoi 0 dessous ?
        ShowMessage(IntToStr(i)); // 0 ??????????????????????????????
        finStream.Position := 0;
        // fmt rempli par LoadFromStream
        af  := fmt.Format;
        acc := fmt.Channels;
        asr := fmt.SampleRate;
        abr := fmt.ByteRate;
        aba := fmt.BlockAlign;
        abps:= fmt.BitsPerSample;
      finally
        Free;
      end;
    Result := True;
  end;
 
begin 
  myfile := '/path/to/agoodfile.wav'; 
  aFileSize := FileSize(myfile);
  SetLength(Buffer, aFileSize);
  for i := 0 to AFileSize-1 do Buffer[i] := 0;
  finStream  := TMemoryStream.Create;
  finStream.LoadFromFile(myfile);
  finStream.Position:=0;
  if LoadFromWav(myfile, Buffer) then begin // pour tester LoadFromWav
    showmessage('LoadFromWav ok, StreamSize = '+IntToStr(finStream.Size)+' '+IntToStr(aFileSize));
                                                      // 441044                        441044
    ShowMessage(inttostr(af)+' '+inttostr(acc)+' '+inttostr(asr)+' '+inttostr(abr)+' '+inttostr(aba)+' '+inttostr(abps));
  //all ok: 1 2 44100 88200 2 8
    finStream.Position:=0;
    for i := 0 to 99 do begin  // pour test des 100 premiers bytes
      finStream.Read(Buffer[i], 1);
      memo.Lines.Add(inttostr(i)+' - '+inttostr(Buffer[i]));
      Application.ProcessMessages;
    end;
  end;
  finStream.Free;
end;

Curieux parce que j'ai écrit il y a quelque temps qu'il manquait des infos dans le fichier généré par TWavWriter et qu'à force de bidouiller ici et là et de lire des trucs à gauche à droite, j'ai fini par enlever les ajouts que j'avais faits dans l'unité fpwavwriter.pas et qu'ensuite, ben... c'est tombé en marche !
C'est peut-être à cause de ça (vu là) : abps := $0002; // ou $0004 ou $0008 que ça coinçait avant.

Ce matin je suis arrivé à ça, qui fonctionne :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
procedure TForm1.btnTestWriterClick(Sender: TObject);
const
  Mono  : Word = $0001; //Son mono
  Stereo: Word = $0002; //Son stereo
var
  buffer: array[0..44099] of byte;
  i,asize,abps,asr,acc: integer;
  SineCount : single;
  Frequency : single;
  Amplitude : double;
 
  function SaveToWav(const aFilename:String; var aBuffer; aBufferSize, aBitsPerSample, aSampleRate, aChannelCount :Integer):Boolean;
  var
    wTmp :TWavWriter;
  begin
    Result := False;
    wTmp := TWavWriter.Create;
    with wTmp do
      try
        StoreToFile(aFilename); // création du fichier récepteur
        // création des données
        fmt.BitsPerSample := aBitsPerSample;
        fmt.SampleRate    := aSampleRate;
        fmt.Channels      := aChannelCount;
        // 2 lignes manquantes :
        fmt.BlockAlign    := aChannelCount * aBitsPerSample div 8;
        fmt.ByteRate      := fmt.BlockAlign * aSampleRate;
        WriteBuf(aBuffer, aBufferSize);
        Result := true;
      finally
        Free;
      end;
  end;
begin
  case rdgSampleRate.ItemIndex of
    0: asr := 8000;
    1: asr := 11025;
    2: asr := 22050;
    3: asr := 44100;
  end;
  asize := SizeOf(buffer);
//showmessage(inttostr(asize)); exit; // 44100
  for i := 0 to asr-1 do buffer[i] := 0; // init buffer
  Amplitude := 0.5;
  Frequency := 440;
  SineCount := 0;
  acc := Mono;
 
// les modifs de la réussite :
//abps:= $0008; // ou $0004 ou $0008
//abps:= $0004; // Wavexplorer -->  "BPS not supported"
  abps:= $0010; // <<<<< Yes !
 
  // write the sine function to the output stream
  for i := 0 to asr-1 do begin
    SineCount := SineCount + (Frequency / asr);
    buffer[i] := Round(Sin(SineCount * 2 * PI) * Amplitude*127);
  end;
end;

Pour vérifier que c'est bon, j'utilise Wavexplorer qui est bien sympa pour des fichiers pas compliqués. En plus on peut voir la sinusoïde et ça, c'est plus agréable qu'une avalanche de bytes.
Voili voilà.
:coucou:

02/02/2023, 14h58
Jipété

Bonjour,

j'ai été un peu absent ces 3 semaines (forum C, bricolages divers et variés à la maison, et un peu ras le bol des soucis du son), je reprends le collier avec une question bête, mais pas tant que ça en fait :

D'habitude on fait des logiciels pour générer des sons. Quelqu'un aurait sous le coude un code pour faire un logiciel d'analyse des sons générés ?
Je m'explique : quand j'écris Frequency := 440; et que j'utilise cette variable pour générer un son, qu'est-ce qui me prouve que ce que j'entends ensuite est vraiment du 440 Hz ?

Il faudrait donc avoir à côté du générateur un autre binaire qui analyserait ce qu'il "entend".
C'est possible ? Ça existe ? Un lien, peut-être ?

Merci, à pluche,
02/02/2023, 16h12
bb84000

Bonjour !

Citation:

Envoyé par Jipété

D'habitude on fait des logiciels pour générer des sons. Quelqu'un aurait sous le coude un code pour faire un logiciel d'analyse des sons générés ?
Je m'explique : quand j'écris Frequency := 440; et que j'utilise cette variable pour générer un son, qu'est-ce qui me prouve que ce que j'entends ensuite est vraiment du 440 Hz ?

Il faudrait donc avoir à côté du générateur un autre binaire qui analyserait ce qu'il "entend".
C'est possible ? Ça existe ? Un lien, peut-être ?,

Si tu ne t'es pas trompé dans ton code, il n'y a aucune raison pour ne pas obtenir 440 Hz. Ou presque.
En effet la précision (ou la justesse) de ton "LA" est liée à la précision de la fréquence d'échantillonnage qui dépend de celle de l'horloge interne de ta machine. Tout logiciel d'analyse que tu exécutes sur cette même machine utilise cette horloge interne. Donc, il va forcément t'indiquer 440 Hz ! Et ceci même avec un échantillon généré sur une autre machine.

Pour voir s'il y a un écart, il te faut utiliser un analyseur qui ne dépende pas de l'horloge interne de ta machine.

bb84000
02/02/2023, 17h11
anapurna

Salut

Pour le coup il faut un fréquencemètre.
En cherchant sur le net je suis tombé là-dessus.
Si tu as un téléphone Android c'est tout bon. ;)
il y a aussi quelques explications sur les différentes fréquences de notes.
02/02/2023, 20h13
Jipété

1 pièce(s) jointe(s)

Bonsoir,

Jouer avec Audacity, ça pourrait fonctionner mais ça dépend des réglages (auxquels je ne comprends rien, avec des nom barbares, lire ci-dessous), et il y a aussi un point noir.

Par exemple, la Fenêtre de Hann (par défaut dans Menu Analyse / Tracer le spectre...) me trouve un pic à 440 Hz quand le même fichier (généré à 440 Hz il y a qq jours par Audacity) observé dans une Fenêtre rectangulaire trouve le pic à 436 Hz ! Retour à 440 avec Bartlett, Hamming, Blackman, Blackman-Harris, Welch (mais tracé trop large), et les 3 Gaussien (le 4,5 ayant le tracé le plus fin, on dirait), cf. copie d'écran sur laquelle j'ai incrusté l'image de ma loupe visant le haut du pic (en mauve)
Pièce jointe 633618

Le tuto de 2 minutes 30 qui m'a mis le pied à l'étrier : https://www.youtube.com/watch?v=KoOTiEksQKI
Écoutez-le bien, il y a un ou deux réglages à prendre en compte (et si j'y suis arrivé, n'importe qui peut le faire aussi).

Et un truc qui me chagrine, avec Audacity : vous avez remarqué, sur ma copie d'écran, les traits rouge, indication de saturation ?
Alors des fois oui et des fois non, c'est quoi ce bazar ? J'avais demandé un son pur (Piste / Nouvelle puis Générer / Tonalité et je mets 0,9999 à l'amplitude), je ne devrais pas avoir de variations, non ?

Bon, je vais me dépatouiller avec ça, mais je suis déçu...

Et juste pour rire, trouvé chez Sonelec ce commentaire à propos d'un fréquencemètre : Le module Compteur / Fréquencemètre a été implémenté en vue de permettre le suivi de la stabilité d'un signal de fréquence fixe, et de tracer dans un fichier de suivi les écarts observés sur une durée déterminée. Pour le moment, la mesure de fréquence manque de précision et ne me convient pas.
Lien (il est plein de trucs Windows, mais je ne sais pas s'il y a les sources).
03/02/2023, 18h43
Guesset

1 pièce(s) jointe(s)

A jeter par les fenêtres ?

Bonjour,

La fenêtre porte ou rectangulaire correspond à l'absence de fenêtre. C'est la pire et seul un nombre important d'échantillons peut en gommer un peu les effets.

Le principe de la transformée de Fourrier est de considérer que le groupe des n échantillons est périodique. C'est le cas si le signal à observer a un nombre de périodes entier dans la fenêtre d'observation de n échantillons. Bien sûr, il est tentant de vouloir alors ajuster cette longueur mais ce n'est pas possible car l'algorithme travaille avec des puissances de 2 et si un programme l'accepte, il va ajouter des points (en général à 0) pour atteindre le 2^p suivant. Ce qui n'arrange pas les affaires.

Que ce passe-t-il quand ça ne tombe pas juste ? Si on prend une sinusoïde... J'ai répété ici 3 fois le même groupe de n échantillons (n = 2048 dans l'exemple communiqué).

Pièce jointe 633671

Dans le premier cas tout va bien, la répétition implicite ne pose pas de problème car la phase ne subit pas de saut.

Dans le second cas (saut de phase apparent en gris), il n'est plus possible de considérer que le signal a la fréquence de la sinusoïde. Le signal analysé a alors 2048 échantillons avant de se répéter ce qui doit faire apparaître une première rai à 44100 Hz / 2048 soit 21.53 Hz. Tout se passe comme si on avait modulé en amplitude le signal par une porte (ce qui est le cas). On a donc un spectre résultant qui transpose (plusieurs fois mais la rai la plus importante est celle de la fréquence du signal à analyser transposée de +/- 21.53 Hz).

Le but des fenêtres plus sophistiquées est d'amener en douceur les échantillons à 0 aux extrémités pour amoindrir ces effets de raccordements. Mais chaque fenêtre vient avec son spectre propre qui altérera toujours celui qu'on veut observer. Rien n'est parfait.

On comprend également que plus le nombre d'éléments est important et moins nous sommes sensibles à ce phénomène. A 4048 la modulation parasite descend est à 10,76 Hz, à 8096 elle n'est plus que de 5,38 Hz et à l'infini il n'y a plus de perturbation. Mais l'infini c'est grand, surtout vers la fin 8-).

J'ai essayé d'expliquer avec les mains, c'est donc un peu approximatif, mais les principes sous-jacents sont là.

Salutations
03/02/2023, 19h23
Jipété

2 pièce(s) jointe(s)

Citation:

Envoyé par Guesset

Mais l'infini c'est grand, surtout vers la fin 8-).

:ptdr: :mouarf: :ccool: :plusser:

Et pour la saturation aléatoire (quantique ?), t'aurais une idée ? Un fichier généré depuis Audacity himself à 440 Hz mono et 0.9999 d'amplitude, en mode PCM16 :

Pièce jointe 633679

Le fichier (désolé pour le zip) : Pièce jointe 633680
04/02/2023, 11h02
Guesset

Pas plus ou moins de ?

Bonjour,

Je suis très loin d'être un spécialiste d'Audacity mais quand je fais un zoom pour voir les échantillons en défaut, c'est toujours quand l'échantillon tombe pile poil sur un extremum. Je pense que l'arrondi à 1 (mais je n'ai pas trouvé comment lui faire afficher l'amplitude d'un échantillon) est considéré comme un dépassement (une comparaison >= au lieu d'un > ? et avec un flottant c'est peut être un truc du genre abs(s) >= 1.0)

C'est un peu excessif, mais je ne crois pas qu'il y ait de quoi se prendre plus la tête.

Attention quand même au mode de visualisation quand le zoom n'est pas suffisant, il y a des trous (sous-échantillonnage à l'écran) et cela rend perplexe quand l'échantillon qui manque est considéré un peu abusivement comme au delà des limites : on a alors une belle verticale rouge mais pas la trace correspondante.

Salutations

6 pièce(s) jointe(s)

Hello,

Citation:

Envoyé par Guesset

--snip--

je réponds à ta réponse, un peu en vrac :

d'abord, je rappelle que c'est audacity qui génère le fichier, donc s'il crée des trous c'est qu'il n'est pas au point, surtout avec ces histoires d'arrondi

Citation:

Envoyé par Guesset

(l'arrondi à 1 (mais je n'ai pas trouvé comment lui faire afficher l'amplitude d'un échantillon) est considéré comme un dépassement (une comparaison >= au lieu d'un > ?))

Moi j'ai pris mon fichier mono de 1 sec à 440 Hz et 16 BPS :
Pièce jointe 633706
puis j'ai zoomé :
Pièce jointe 633707
Pièce jointe 633708
Pièce jointe 633709
zoomé à mort :
Pièce jointe 633710

Ensuite j'ai refait la manip mais pas les copies d'écran en choisissant une onde qui monte :
Pièce jointe 633705
En haut audacity et son zoom à bloc, dessous l'éditeur hexa : j'ai mis en surbrillance le 1 qui est le premier byte des 8 de la taille des data (le tag data est juste avant, 64 61 74 61).
On part de ce '1' puis
16 00 00 00 = 22 en décimal et nous avons donc bien 22 blocs de 2 bytes, soit 11 samples en 16 bits.
Ensuite j'ai analysé blocs de 16 par blocs de 16 :
de gauche à droite après ce 16 00 00 00 :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 ord valhex valdéc 01--D7 79 = 31191 02--0C 7C = 31756 03--C9 7D = 32201 04--04 7F = 32516 05--C0 7F = 32704 06--FE 7F = 32766 le trait rouge 07--B6 7F = 32694 08--F4 7E = 32500 09--AD 7D = 32173 10--EB 7B = 31723 11--AB 79 = 31147
Qui pourra expliquer pourquoi j'ai un trait rouge à 32766 quand on l'aurait attendu à 32767 ?
Tu dois avoir raison avec ta comparaison erronnée !
Mais franchement, flemme de chercher les sources pour modifier et recompiler et retester.

Ensuite j'ai fait la même manip avec une onde qui descend puis remonte (c'est l'image "zoomé à mort") :
Code:

1 2 3 4 5 6 7 8 9 10 11 01--36 86 = 34358 02--00 84 = 33792 03--42 82 = 33346 04--FE 80 = 33022 05--46 80 = 32838 06--00 80 = 32768 le trait rouge -- en suivant la logique de l'erreur de comparaison, j'aurais dû avoir 32769 puisque 32768 est dans la fourchette... 07--49 80 = 32841 08--07 81 = 33031 09--47 82 = 33351 10--0D 84 = 33805 11--44 86 = 34372
Va falloir que j'écrive un truc pour me récupérer tous les points max et min, pour essayer de comprendre.
À moins que quelqu'un ait ça dans un coin ?
Parce que les outils audacity, euh... j'ai essayé d'utiliser un plug-in Nyquist (qu'il faut activer), le mesureur RMS, et franchement, entre 0 doc et aucun réglage, le truc m'a affiché -3.01071 dB sur une partie sélectionnée où il y a de la saturation : le temps que je perds avec ces trucs...

Et si je fais Menu Analyse / Montrer la saturation et que je valide la petite fenêtre, que je conserve les défauts 3-3 ou que je passe à 1-1, dans les deux cas l'affichage n'affiche rien !

Ah, un truc très bizarre : ici l'onde descend jusqu'au fond puis remonte, mais les valeurs hexa montrent l'inverse : pas compris...
Regardez bien le second tableau de valeurs, :koi:

Bref, pour en finir mais sans savoir pourquoi ni comment, je n'ai plus de saturation de traits rouges dans le fichier que je fais générer SI je demande une amplitude à 0,99 plutôt à 0.9999.
Mais c'est complètement pifométrique, ça, et je ne veux pas vous perdre avec des copies d'écran où on ne comprend rien.
Faudrait que je me tape une analyse comme celle qui précède, mais flemme...

C'est tout pour le moment, cet aprème, relâche !
:coucou:

04/02/2023, 19h16
Guesset

Un clou manque...

Bonjour,

Il y a un truc que je ne comprends pas. Il affiche un format flottant 32 bits mais les valeurs extraites du fichier sont en 16 bits. Il y aurait peut être des conversions/normalisations, genre s/32767.0, avant comparaison que cela pourrait déjà semer la zizanie au moins sur le valeur à -32768.

32768 est la plus petite valeur négative, 1 de moins et on repasse en positif. C'est même une valeur critique car - $8000 = $8000 (comme un 0 négatif :roll:). Par raison de symétrie, le maximum étant de +32767 on peut comprendre une certaine intolérance à avoir une valeur négative < -32767.

Ceci n'explique nullement qu'il considère déjà en faute le +32766.

Tout se passe comme s'il retirait une unité à la gamme "normale" -32767 .. +32767 qui devient -32768 .. +32766. Pourquoi ? Euh...

Ceci étant, en 16 bits, il est obligé d'être (abusivement) strict car il ne peut y avoir des valeurs qui excèdent les possibilités de cette numération (donc stricto sensu pas de saturation) : $8000 .. $FFFF, 0, $0001 .. $7FFF soit -32768 .. -1, 0, 1 .. +32767 (avec la réticence sur $8000). Il considère peut être alors que le maximum est déjà le fuit d'un écrêtage ce qui peut se comprendre nonobstant les bizarres valeurs seuils qu'il retient. Un peu comme en photo où on considère les zones blanches comme grillées alors même que le blanc fait partie de la gamme.

Salutations
04/02/2023, 20h08
Jipété

Citation:

Envoyé par Guesset

Il y a un truc que je ne comprends pas. Il affiche un format flottant 32 bits mais les valeurs extraites du fichier sont en 16 bits.

C'est la puissance d'Audacity : il fait tout en flottant et complètement à la fin, quand on veut enregistrer le fichier résultant de notre laborieux travail, on a le choix dans la boîte de dialogue "Enregistrer sous..." entre tout un tas de formats dont certains je n'en avais même jamais entendu parler !

Citation:

Envoyé par Guesset

Ceci n'explique nullement qu'il considère déjà en faute le +32766.

C'est bien la remarque que je me suis faite.

Citation:

Envoyé par Guesset

Un peu comme en photo où on considère les zones blanches comme grillées alors même que le blanc fait partie de la gamme.

Ça dépend de ce qu'on photographie : s'il s'agit du drapeau français, il vaut mieux que le blanc soit blanc, grillé même, puisqu'on ne verra pas la différence.
Mais s'il s'agit d'un joli paysage de printemps et que tu as foiré son exposition, genre très sur-ex', tu ne le rattraperas pas, même en allant chercher dans les données raw : si plein de pixels du capteur ont basculé au-delà de 255 255 255, c'est mort, c'est blanc de chez blanc, tu as "cramé" ton ciel par exemple.

Bonjour,

Mon analyseur des data WAVE avance pas trop mal, pour le moment il n'y a que l'option 16 bits, mais ça permet de voir des trucs et de se taper la tête contre les murs : il y a deux jours je récupère d'un podcast de France-Musique une chanson de 2 minutes et quelques, je l'édite avec Audacity (enlever les choses incongrues au début et à la fin, relever le niveau général jusqu'à atteindre -0,1 dB et rajouter un fondu à la fermeture), tout est parfait, il n'y a aucun trait rouge donc pas de saturation donc j'enregistre le fichier en signed 16 bits et tout est bien qui finirait bien...

Car là maintenant, je l'analyse et je constate qu'il y a quand même des pointes à FFFF (65535), 4305 très exactement, et zéro trait rouge, on vient de le lire au § précédent.

Conclusion : les traits rouges que j'ai remarqués il y a qq jours avec d'autres fichiers doivent venir d'une étape intermédiaire dans le traitement des données par Audacity car je rappelle une vieille manip mortelle :

générer un fichier avec l'amplitude à 0,9999 va donner un graphique avec des traits rouges,
générer un fichier avec l'amplitude à 0,9900 va donner un graphique sans les traits rouges.

(et on sait qu'Audacity travaille en flottant en interne -- ça doit jouer...)

Or l'analyse de ces deux fichiers avec mon nouvel outil montre qu'ils ont tous les deux des max à FFFF, ce qui a l'air de confirmer mon idée de l'indication d'une saturation aléatoire dans les étapes intermédiaires, indépendamment du contenu du fichier, ce qui ne me convient pas du tout !

Et je n'ai pas de solution, à part tweaker aux petits oignons un générateur perso de fichiers. À suivre...

Mais d'abord il faut finir l'analyseur, il lui manque l'analyse des fichiers en 8 et 32 bits (24 je renonce, c'est trop compliqué et je n'en ai jamais vu à part dans des dossiers pour tests).

Ci-dessous ce que produit mon analyseur avec en haut le fichier "saturé" (je mets le mot entre guillemets car je ne vois pas où c'est saturé), et dessous le même non saturé.
C'est normal qu'il y ait des différences dans les data intermédiaires, ce n'est pas normal qu'en ayant les max à 65535 pour les deux, l'un affiche des traits rouges et pas l'autre.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Fichier audac_1secM16pcm0,9999.wav Bytes par sample : 2 Passe 1 : trouver la plus grande valeur Adr 1er byte Valeur déc | hex déc | hex 46 2E 2053 0805 48 30 4097 1001 50 32 6125 17ED 52 34 8131 1FC3 ... 3552 DE0 65491 FFD3 4454 1166 65532 FFFC 13274 33DA 65535 FFFF Passe 2 : noter positions et quantité Adresses val 65535 | FFFF déc | hex 13274 33DA 22094 564E 35324 89FC 57374 E01E 70604 113CC Total : 5 entrées +++++++++++++++++++++++++++++++++++++++++++++ Fichier audac_1secM16pcm0,9900.wav Bytes par sample : 2 Passe 1 : trouver la plus grande valeur Adr 1er byte Valeur déc | hex déc | hex 44 2C 65535 FFFF Passe 2 : noter positions et quantité Adresses val 65535 | FFFF déc | hex 44 2C 39734 9B36 75014 12506 Total : 3 entrées
Et je n'ai pas trouvé comment faire afficher les valeurs des points quand on zoome à mort, pour confirmer l'hypothèse.
:coucou:
(et désolé pour l'affichage un peu déglingué ci-dessus)

Voir 40 message(s) de cette discussion en une page