[K] FileImporter 3.1 - a jednak!

Tak to jest, że człowiek przewiduje jedno, a dzieje się coś innego. Nie minął nawet miesiąc od poprzedniego wpisu na temat FileImportera, a pojawiło się całkiem sporo potrzeb, które doprowadziły do powstania wersji 3.1.

Nowe importery

Najpilniejszą potrzebą było dopisanie dwóch importerów dla dwóch nowych rejestratorów audio. Chodzi o nie opisywane jeszcze na łamach bloga Zoom H1 Essential oraz (uwaga!) SoundDevices MixPre-6 II. Pierwszy z importerów, czyli ten dla Zoom H1e, był względnie prosty, bo bardzo mało różnił się od importera dla H1n - prosta lista plików o czytelnych nazwach, możliwość usuwania. Trzeba było tylko zmienić sposób detekcji i w zasadzie gotowe - w kodzie źródłowym różne były dosłownie trzy linijki.

Importer dla Zooma H1 Essential, nic specjalnego

Z MixPre-6 było już gorzej, bo należy on do rejestratorów stosujących "hierarchię", czyli kolejne sesje nagraniowe są umieszczone w podkatalogach. W przypadku prostego importera, takiego jak ten dla H1e, sprawa jest trywialna - odczytujemy jeden katalog, w którym zgromadzone są odpowiednio nagrane pliki wav i tyle. W przypadku importera dla MixPre-6, Zooma Podtraka P4 czy RødeCastera 2 Pro trzeba już przebić się przez strukturę katalogów, pogrupować pliki itp. Całe szczęście, że też większość roboty miałem zrobioną, chociaż tu już trzeba było trochę programować, żeby np. odpowiednio zmienić nazwy plików wav (które w MixPre-6 są budowane podobnie jak w Røde Wireless, czyli stały człon nazwy i numer).

Pewnym problemem w przypadku MixPre-6 jest fakt, że tu nagrania dokonywane są w wielościeżkowych pojedynczych plikach wav i żeby dostać monofoniczne nagranie mikrofonu podpiętego do wejścia nr 2, trzeba najpierw taki "duży" plik rozbić na poszczególne kanały. Ale i tu poradziłem sobie w miarę gładko, bo od dłuższego już czasu korzystam z programu sox.exe, którego obecnie wspieram odpowiednimi skryptami w Pythonie. Wystarczyło zatem użyć akcji, wprowadzonych w wersji 2.5, by wywołać odpowiednio spreparowany skrypt pythonowy i gotowe, zgrany plik wielokanałowy "sam" dzieli się na mniejsze części.

UCS

Nowe importery nie wystarczyły jednak, by zmienić numerację aż na 3.x. Musiało się w programie pojawić coś więcej - i owszem, jest coś więcej. W 2022 roku, w związku z rozpoczęciem nagrywania dźwięków różnych, głównie w terenie, napisałem sobie program UCSHelper. Służył on do nazywania zgrywanych plików wav i umieszczania ich w strukturze katalogów zgodnej z Universal Category System (stąd nazwa). To bardzo przydatny system, który niejako automatycznie dokumentuje pliki. A że używam także programu BaseHead, który także wspiera UCS, to chcę nadal zgrywać pliki w taki właśnie sposób.

Kłopot z UCSHelperem był taki, że po pierwsze był on nieco skomplikowany w użyciu, a po drugie stosował własną "bazę danych" o plikach, co dublowało funkcjonalność (dużo większą) BaseHeada. Pomyślałem, że FileImporter jest bardzo dobrym miejscem, żeby jednak ułatwić sobie życie i tak pojawiła się dodatkowa zakładka, nazwana... UCS:

Szybka przeglądarka UCS - kategorie sprzężone z katalogami, widać, gdzie są już jakieś zgrane pliki

Można tu zrobić dwie rzeczy: po pierwsze dość sprawnie przejrzeć strukturę katalogów UCS, bo program odpowiednim kolorowaniem wskazuje, które z katalogów zawierają jakiekolwiek pliki - po namierzeniu pliku można go odtworzyć lub otworzyć w zewnętrznym programie (w moim przypadku jest to TotalCommander).

Eksport do UCS to teraz nic strasznego, urządzenie wypełnia się samo, wystarczy wybrać kategorię i już

Po drugie, na "pod-zakładce" Export można wskazać dowolne pliki z dowolnego katalogu, wskazać urządzenie, którym były nagrane, przypisać do kategorii i przenieść do struktury UCS z jednoczesną zmianą nazw plików na zgodne ze standardem. Plusem tego, że zrobiłem tę funkcjonalność w FileImporterze jest fakt, że jeśli wybiorę pliki z katalogu, który FileImporter "zna", bo jest do tego katalogu przypisany któryś z importerów, to automatycznie ustawia mi się urządzenie nagrywające, więc opis pliku staje się czytelniejszy. Fajnie byłoby jeszcze przenosić nazwy mikrofonów - co jest do zrobienia, bo FileImporter przy zgrywaniu plików z rejestratorów, jeśli zaznaczono wykorzystany mikrofon, zapisuje te informacje w metadanych i w specjalnym pliku tekstowym. Na razie jeszcze w to nie wchodziłem, ale konwencja UCS przewiduje tego typu adnotację w nazwie pliku.

Dość tego

Jak widać, kilka wypadów w teren i konieczność zgrywania wielu nagrań z wielu rejestratorów sprawiły, że pojawiły się nowe potrzeby. I dobrze, niech się FileImporter rozwija, póki działa szybko i niezawodnie.

Teraz musiałbym się skupić na detalach w rodzaju wspomnianego wyżej opisywania plików także nazwami mikrofonów. Musiałbym też przemyśleć budowę importera i być może zbudować coś, co nie będzie wymagało tworzenia importerów w kodzie źródłowym, tylko ich "skonfigurowanie" za pomocą pliku xml/json. Wtedy - tak zakładam - dodawanie kolejnych importerów stałoby się banalne...