-
Notifications
You must be signed in to change notification settings - Fork 0
Description
The id3scan
tool creates files like this:
garth_brooks_no_fences-1990-album.xml
garth_brooks_no_fences-1990-audiocd.xml
garth_brooks_no_fences-1990-cd01-index.xml
With a little work, it could create files and directories like this:
garth_brooks/no_fences-1990-album.xml
garth_brooks/no_fences-1990-audiocd.xml
garth_brooks/no_fences-1990-cd01-index.xml
Or maybe like this:
garth_brooks/garth_brooks_no_fences-1990-album.xml
garth_brooks/garth_brooks_no_fences-1990-audiocd.xml
garth_brooks/garth_brooks_no_fences-1990-cd01-index.xml
The idea is to reduce the clutter in the outdir
path where all the XML files get written.
Right now my workflow is this:
- Keep a persistent
outdir
lines data tied to an iTunes library. - For new iTunes imports, re-run the id3scan using the same path for the output files.
- The
id3tool
will only generate new files because it will detect the existing files already in the path.
- The
- Copy the new files to another host with an actual git repository
So the outdir path is kind of a dumping ground with about 4000 files. If the id3scan tool can make directories, it could make it more manageable.
It should be available as an option, so users can choose which method to lay out the files. Also, the code should still be able to identify existing files and not overwrite anything that doesn't need it.
In the case the --split-xml
option is used, the code needs to generate xi:include
elements that make sense to reference the proper files.
Finally, everything still needs to be readable from tools like the XML validator, or the medialibrary
tools.