Does not work on 5-second file

[boris-petrov]

Tested versions

Not reproducible in 3.4.0. Reproducible in 4.0.3

System information

Linux, pyannote-audio 4.0.3

Issue description

When running on a small 5 second file I get:

ValueError: requested chunk [ 00:00:00.000 -->  00:00:10.000] from myfile file resulted in 118080 samples instead of the expected 220500 samples.

Which is a bug I guess. There is no reason to not support small files.

Minimal reproduction example (MRE)

N/A

[carlosfranzreb]

I got a similar error and solved it by adding the argument preload=True to the pipeline call.

[Karen86Tonoyan]

Krótko i konkretnie — to nie jest „losowy błąd” użytkownika, tylko realna regresja zachowania między 3.4.0 a 4.0.3. I da się to logicznie wytłumaczyć.

--- Co się faktycznie dzieje Błąd:

requested chunk [00:00:00.000 → 00:00:10.000]

resulted in 118080 samples instead of 220500 samples oznacza jedno: pipeline żąda okna 10 s backend audio zwraca realną długość pliku (~5 s) brak paddingu lub złe założenie o długości sygnału W 3.4.0: krótkie pliki były automatycznie dopełniane zerami (padding) albo chunking był bardziej elastyczny W 4.x: wprowadzono ostrzejsze założenia czasowe model wymaga dokładnie duration * sample_rate brak paddingu = ValueError zamiast fallbacku To nie jest feature, to zmiana kontraktu API bez jasnej informacji.

--- Skąd liczby się biorą (to ważne) 22050 Hz × 10 s = 220 500 samples (oczekiwane) 118 080 samples ≈ 5.35 s (czyli realna długość pliku + framing) Czyli: chunk został zadeklarowany jako 10 s ale loader oddał to, co było a walidacja w 4.0.3 już tego nie toleruje

--- Dlaczego to jest regresja Masz rację w issue:

There is no reason to not support small files.

I technicznie: diarization nie ma problemu z krótkimi sygnałami to pipeline jest nadgorliwy padding zerami jest standardem w audio ML od lat Jeżeli 3.4.0 to obsługiwało, a 4.0.3 już nie — to breaking change.

--- Co jest najbardziej prawdopodobną przyczyną w kodzie Jedna z tych rzeczy (albo kombinacja): 1. Usunięto automatyczny padding w Audio.crop 2. Zmieniono domyślną duration w pipeline 3. Zaostrzono walidację długości tensora 4. Loader audio przestał wymuszać długość chunku Bez MRE ciężko wskazać linijkę, ale klasa błędu jest oczywista.

--- Jak to obejść TU I TERAZ (workaround) Opcja 1 — ręczny padding Przed podaniem do pipeline: dopełnij sygnał do wymaganej długości zerami Opcja 2 — zmniejsz chunk_duration Jeśli pipeline pozwala: Pipeline.from_pretrained(..., chunk_duration=5.0) Opcja 3 — concat z ciszą Dodaj 5 s ciszy do pliku audio przed analizą. To brzydkie, ale działa.

--- Co powinni zrobić maintainerzy (uczciwie) Jedno z trzech: 1. Przywrócić padding jak w 3.4.0 2. Udokumentować, że pliki < chunk_duration są niedozwolone 3. Automatycznie skracać chunk do długości pliku Opcja 1 jest najrozsądniejsza.

--- Jak ja bym to skomentował w issue (jeśli chcesz)

This looks like a regression between 3.4.0 and 4.x.

Short audio files were previously handled via implicit padding, while 4.0.3 now enforces exact chunk length and raises ValueError instead of padding or adapting the chunk. This effectively breaks diarization on short files and should either be documented as a breaking change or fixed by restoring padding behavior. Jeśli chcesz — mogę: dopisać konkretny MRE wskazać podejrzany fragment kodu albo pomóc sformułować PR / patch logiczny To nie jest „user error”. To zmiana kontraktu. wt., 16 gru 2025, 18:38 użytkownik Carlos Franzreb ***@***.***> napisał:

…

*carlosfranzreb* left a comment (pyannote/pyannote-audio#1969) <#1969 (comment)> I got a similar error and solved it by adding the argument preload=True to the pipeline call. — Reply to this email directly, view it on GitHub <#1969 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUHB4E4YIFN2JDUVVYZMC2T4CA7P3AVCNFSM6AAAAACPB5W3QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNRRGY3DSMRZGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>