Mon audio est-il suréchantillonné ?

Pour qui

Vous constituez ou achetez de la parole pour un jeu de données qui doit être en large bande, et vous voulez savoir quels fichiers ne font que le paraître. La fréquence d’échantillonnage dans l’en-tête dit comment un fichier est stocké, pas ce qu’il contient : un appel téléphonique stocké à 16 ou 48 kHz s’arrête quand même vers 4 kHz.

Cette page vous donne un appel, un champ à lire et quoi faire de chaque réponse. Vous n’avez pas besoin de savoir comment le moteur décide : les limites sont dans la réponse elle-même.

1. Appelez-le

Activez bandLimit dans une requête à l’analyse du signal. Pour un fichier local avec curl :

curl -s "https://audiolab.tools/v1/signallab?bandLimit=true" \
  -H "Authorization: Bearer $AUDIOLAB_KEY" \
  -F file=@recording.wav

Pour un fichier à une URL publique, envoyez du JSON :

curl -s https://audiolab.tools/v1/signallab \
  -H "Authorization: Bearer $AUDIOLAB_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/recording.wav", "bandLimit": true}'

Avec le client Python (pip install audiolabtools), d’abord un fichier, puis un dossier, 20 fichiers à la fois, vers un CSV :

import csv
from pathlib import Path

from audiolabtools import AudioLab

lab = AudioLab()  # reads AUDIOLAB_KEY

band = lab.signal("recording.wav", bandLimit=True)["bandLimit"]
print(band["upsampled"], band["reason"])

files = sorted(str(p) for p in Path("recordings").glob("*.wav"))
with open("upsampled.csv", "w", newline="", encoding="utf-8") as f:
    out = csv.writer(f)
    out.writerow(["file", "upsampled", "ratio", "reason"])
    for i in range(0, len(files), 20):
        chunk = files[i : i + 20]
        answer = lab.batch(chunk, endpoint="signallab", bandLimit=True)
        for name, r in zip(chunk, answer["results"]):
            b = (r.get("data") or {}).get("bandLimit") or {}
            out.writerow([name, b.get("upsampled", "error"), b.get("ratio"),
                          b.get("reason", r.get("error"))])

Dans un assistant IA avec le serveur MCP d’AudioLab (version 0.5.1 ou ultérieure), index_signal accepte l’option bandLimit: true, et analyze_batch aussi, avec endpoint: "signallab/index", pour 20 fichiers à la fois. Demandez par exemple : « Lesquels de ces enregistrements ont été suréchantillonnés ? »

Chaque fichier est un appel et est envoyé à l’API, hébergée dans l’UE ; seuls des chiffres reviennent. Pour un grand dossier, l’audit d’un jeu de données a un script complet qui règle son rythme, peut tirer un échantillon et reprend là où il s’est arrêté.

2. Lisez un champ

Lisez bandLimit.upsampled. C’est yes, no ou cannot-say. À côté, bandLimit.reason dit la même chose en mots simples, avec la bande passante et la fréquence d’échantillonnage : reprenez la phrase telle quelle dans votre rapport. Voici la réponse pour un enregistrement que nous avons ramené à 8 kHz puis remonté à 16 kHz :

{
  "bandLimit": {
    "upsampled": "yes",
    "status": "validated",
    "reason": "The band stops at 4.3 kHz in a 16 kHz file: the audio was probably at 8 kHz or less, as in a telephone call, before it was stored at this rate. In study UP-1, 0.1 to 1.8% of untouched recordings read the same way.",
    "basis": [
      {
        "check": "telephone-origin (UP-1)",
        "status": "validated",
        "result": "fires"
      },
      {
        "check": "band-limit ratio (UP-2)",
        "status": "proxy",
        "result": "band-limited",
        "ratio": 0.537
      }
    ],
    "bandwidthHz": 4296.9,
    "sampleRate": 16000,
    "ratio": 0.537,
    "verdict": "band-limited",
    "reasonCode": "ratio-below-L"
  }
}

status ne vaut validated que pour un yes. basis liste chaque condition sur laquelle repose la réponse, avec son propre statut, pour que vous voyiez pourquoi. Vous n’en avez pas besoin pour agir.

3. Quoi faire de chaque réponse

upsampled	Ce que cela veut dire	Ce que vous faites
yes	La bande s’arrête sous 5 kHz dans un fichier de 16 kHz ou plus, pendant au moins 2 secondes : l’audio était probablement à 8 kHz ou moins, comme dans un appel téléphonique, avant d’être stocké à cette fréquence. Statut validated (étude UP-1).	Ne l’utilisez pas comme vraie large bande.
no	La bande atteint la moitié de la fréquence d’échantillonnage : aucun signe de suréchantillonnage. Statut proxy (étude UP-2).	Rien à faire.
cannot-say	Tout le reste : une bande qui s’arrête tôt sans le motif téléphonique, une bande entre 80 et 90 pour cent de la moitié de la fréquence, un fichier de moins de 2 secondes, un spectre tonal ou du silence. La raison dit lequel.	Mettez-le de côté. Si votre jeu de données ne doit contenir que de la vraie large bande, écartez-le ou écoutez-le. S’il vous faut un nombre pour filtrer, bandLimit.ratio est la bande passante divisée par la moitié de la fréquence d’échantillonnage.

Pourquoi une bande qui s’arrête seulement tôt n’est pas un yes : une source étroite a la même allure. Dans l’étude UP-2, un locuteur de LibriSpeech, enregistré à sa propre fréquence, a été lu comme limité, et un micro ou un filtre qui coupe les aigus fait de même.

4. Combien de fois chaque réponse est sortie dans nos tests

Nous avons relu les enregistrements des deux études avec la décision, le 10 novembre 2026. Les deux règles étaient fixées avant que ces études ne tournent, et la façon dont elles donnent une seule réponse était fixée avant cette lecture. C’est donc une description de la façon dont tombent les trois réponses, pas un nouveau test. Les enregistrements d’UP-1 ont été lus deux fois, à leur propre fréquence et décodés à 48 kHz : les comptes sont des lectures, pas des fichiers.

Type d’enregistrement	Lectures	yes	no	cannot-say
Passé par un codec téléphonique 8 kHz et remonté à 16 ou 48 kHz (UP-1 : G.711, AMR, GSM)	4 692	4 608 (98,2 %)	0	84 (1,8 %)
Passé par un codec téléphonique (UP-2 : AMR, G.711, GSM)	90	90 (100 %)	0	0
Suréchantillonné depuis 4 kHz	450	443 (98,4 %)	0	7 (1,6 %)
Suréchantillonné depuis 8 kHz	450	436 (96,9 %)	0	14 (3,1 %)
Suréchantillonné depuis 11,025 kHz	450	1 (0,2 %)	0	449 (99,8 %)
Suréchantillonné de 16 kHz vers 44,1 ou 48 kHz	3 428	5 (0,1 %)	0	3 423 (99,9 %)
Parole de FLEURS à ses propres 16 kHz	1 082	14 (1,3 %)	1 032 (95,4 %)	36 (3,3 %)
Parole de LibriSpeech à ses propres 16 kHz	150	0	141 (94,0 %)	9 (6,0 %)
Parole coupée à 6 kHz, à ses propres 16 kHz	782	17 (2,2 %)	1 (0,1 %)	764 (97,7 %)
Parole passée par un codec avec perte (MP3 32 à 128 kbit/s, AAC 48, Opus 16)	300	0	130 (43,3 %)	170 (56,7 %)

Ce que cela veut dire pour vous :

• Aucune lecture suréchantillonnée n’a reçu no : 0 sur 9 560.
• yes trouve le motif téléphonique et le suréchantillonnage depuis 4 ou 8 kHz. Un suréchantillonnage depuis 11,025 kHz ou plus sort en cannot-say, presque jamais en yes. Lisez donc cannot-say comme « à regarder », pas comme « probablement bon ».
• Sur de la parole à sa propre fréquence, un yes était faux pour 14 lectures FLEURS sur 1 082 (1,3 %) et pour aucune des 150 lectures LibriSpeech. La parole coupée à 6 kHz a lu yes dans 17 cas sur 782 (2,2 %).

Ce que cela ne voit pas

• Les vraies lignes téléphoniques, les codecs VoIP (Opus, G.722) et les casques Bluetooth. UP-1 a utilisé des codecs téléphoniques que nous avons fait tourner nous-mêmes.
• Les enregistrements natifs à 44,1 ou 48 kHz : combien de fois ils liraient cannot-say n’est pas mesuré. Une source à 44,1 kHz stockée à 48 kHz lit no ; la règle ne voit pas ce pas.
• Un suréchantillonneur qui invente lui-même des hautes fréquences, comme un modèle qui restaure la bande, lit no.
• Il ne nomme pas de fréquence d’origine, sauf pour l’origine téléphonique.

Les deux études, avec leur préenregistrement et leur résultat, sont sur la page des études. Ce sur quoi la limite de bande a été testée est aussi sur sa page.