Awesome-TTS Dateinamen

Einige kennen sicher das genial Anki AddOn Awesome-TTS. Es erlaubt Text über eine TTS Engine in MP3 zu wandeln und als Audio in seine Karteikarten zu integrieren.

Das ansich perfekte Plugin hat jedoch einen Nachteil … Es erzeugt unnötig lange Filenamen wie S1+E3818BE381B0E38293E3818CE4B880E381A4E381A0E38191E38182E3828AE
381BEE38199E38082S2+E3818BE381B0E38293E3818CE4B880E381A4E38197E3
818BE38182E3828AE381BEE3819BE38293E38082.mp3

In Kombination mit meinem QR-Code-Mechanismus ist das ein ziemliches No-Go, weil durch die lange Länge der Filenamen, werden die QR-Codes entweder größer oder dichter, weil mehr Informationen in den Code gepackt werden muss.

Für bestehende MP3-Files hat mein QR-Code Plugin eine Zusatzfunktion, die die MP3-Files MD5-Summt und entsprechend der MD5-Summe umbenennt. Alle Files haben dann die gleiche Dateinamen-Länge und damit alle QR-Codes die gleiche Density.

Weiterhin erlaubt es außerdem, dass identischer Text mit unterschiedlichen TTS-Einstellungen auch unterschiedliche Filenamen bekommen.

Damit es aber garnicht soweit kommt, habe ich Awesome-TTS auf github geforkt und es entsprechend angepasst, damit es von sich aus schon richtige Dateinamen erzeugt.

Hunderprozentig glücklich bin ich aber noch nicht, weil Dropbox irritiert werden könnte, wenn für jedes File erstmal ein zufällig gewählter Dateiname erzeugt wird und das File dann gleich wieder gelöscht wird. Ein einziger zufällig gewählter Dateiname würde reichen … Eigentlich wäre nicht mal das notwendig … Wer betreibt schon mehrere Ankis gleichzeitig? Und die Implementierung des Mass-MP3-Generators ist auch nicht multithreaded … Mal kucken 🙂

https://github.com/shufps/AwesomeTTS

Gleichzeitig hab ich auch diesbezüglich ein Issue im Github Bug-Tracker aufgemacht, weil mir nicht klar ist, wieso der Autor damals diese Entscheidung mit den Dateinamen getroffen hat … Unnötig komplex meiner Meinung nach …