[K] FileImporter 4.2 - zmiany małe, ale ważne

Od poprzedniej wersji 4.1 w interfejsie użytkownika nie zmieniło się wiele - za to pojawiły się zmiany wewnętrzne, częściowo podyktowane współpracą ze skryptami pythonowymi. Już tłumaczę, o co chodzi.

FileImporter to nie wszystko

Od dawna (a zaryzykuję stwierdzenie, że od samego początku) FileImporter ściśle współpracował z rozmaitymi skryptami narzędziowymi, które pisałem sobie w Pythonie. Chodziło przede wszystkim o utrzymanie porządku w plikach, co przy importowaniu wielu nagrań z różnych urządzeń nie jest łatwe.

O ile zwykłe nagrania, dajmy na to - odcinki podcastu - są w miarę proste w zarządzaniu, to już pliki terenowe z przeznaczeniem do wrzucenia na freesound.org czy dzienniki audio stanowiły od zawsze pewne wyzwanie. W ostatnim czasie dokonałem małej rewolucji zwłaszcza w tej drugiej grupie.

Od jesieni 2023 FileImporter zapisuje w importowanych plikach metadane, takie jak użyte urządzenie nagrywające oraz mikrofon (jeśli go wskazałem przed importem). Potem te metadane są także transferowane do plików mp3, które tworzy specjalny skrypt pythonowy, uruchamiany po zakończeniu importu przyszłego dziennika audio. Skrypt ten między innymi przeprowadza prostą normalizację plików, by wszystkie "dzienniki" miały tę samą odczuwalną głośność oraz dokonuje konwersji na format mp3 (dzienniki nie muszą być archiwizowane w źródłowej postaci). Skrypt przepisuje też metadane z pliku wav do mp3.

Przez dłuższy czas mi to wystarczało - nazwa dziennika zawierała datę wykonania nagrania, a po włączeniu odtwarzania widać było, jakim sprzętem dziennik został nagrany. Pięknie.

Metadane z dzienników audio widoczne w odtwarzaczu Foobar2000

Kłopot w tym, że dzienników najczęściej słucham w smartfonie, korzystając wprost z aplikacji Google Drive. Dlaczego kłopot? Bo Google Drive nie wyświetla w postaci listy metadanych ani czasu trwania pliku mp3 - to da się sprawdzić dopiero po uruchomieniu odtwarzania. A jeśli mam kilkaset dzienników, nagranych na przestrzeni niemal sześciu lat, trudno jest pamiętać na przykład, który plik zawiera półgodzinne pierwsze nagranie z mikrofonu Neumann TLM102.

Postanowiłem zatem inaczej zorganizować dzienniki - odtąd ich nazwa zawiera nie tylko datę, ale także czas trwania oraz kodowy symbol mikrofonu, którym dziennik był nagrany. Pomysł był prosty, wykonanie także, nawet napisanie prostego skryptu, który przerobi już istniejących kilkaset nagrań nie stanowiło problemu.

Teraz nawet na liście Google Drive wszystko jest jasne

No i na koniec trzeba było jeszcze dostosować FileImportera, by zapewnił dostęp do odpowiednich danych.

Jeszcze więcej informacji

Przy okazji okazało się, że o ile do tej pory nie potrzebowałem szczegółowych informacji na temat wykonania zewnętrznych skryptów z poziomu FileImportera, to teraz przydałoby się odczytywać nie tylko kod zakończenia wykonania (0 - wszystko ok, inna wartość - błąd). Zmian wymagała procedura uruchamiająca zewnętrzne skrypty i to w taki sposób, żeby wszystko, co taki skrypt normalnie wypisuje na konsoli, trafiło do logów FileImportera. Bez tego namierzanie błędów jest niezmiernie utrudnione - a te zdarzają się, bo FileImporter robi mnóstwo rzeczy "pod spodem", czego nie widać z poziomu prostego - było nie było - interfejsu programu.

Przykładowo - zgranie pojedynczej ścieżki z SoundDevices MixPre6 nie polega tylko na prostym skopiowaniu pliku z rejestratora na dysk komputera. Trzeba konkretną ścieżkę "wydobyć" z wielościeżkowego pliku wav, potem ją odpowiednio nazwać, zapisać do niej metadane, a jeśli ma to być dziennik audio, to FileImporter uruchomi odpowiedni skrypt w Pythonie, który zmieni nazwę pliku na zgodną ze schematem nazwy dziennika, umieści w tej nazwie czas trwania i symbol mikrofonu, przeprowadzi normalizację, a potem jeszcze zamieni znormalizowany plik na mp3, skopiuje do niego metadane, a sam plik przeniesie do folderu, gdzie gromadzę dzienniki. A i to jeszcze nie koniec, bo stworzenie dziennika obejmuje też sporządzenie transkrypcji za pomocą Whispera. Jak widać, procedura jest długa i warto byłoby mieć w miarę szczegółowy jej zapis w logu, żeby w razie czego móc dojść do przyczyny, dlaczego coś się nie powiodło...

Bez obrazków

Takie oto zmiany zawiera właśnie wersja 4.2 - w interfejsie użytkownika nie pojawiło się dosłownie nic nowego, żadna ekscytująca funkcja. Za to pod spodem - wierzcie lub nie - pojawiło się całkiem sporo rzeczy związanych z nudnym zarządzeniem plikami, zapisywaniem logów i odnotowywaniem, co, jak i kiedy się dokonało. I dobrze, takie wersje też się przydają, i one także posuwają rozwój programu naprzód.