Ha! You and me both. I posted nearly two weeks ago, but didn't get around to checking back until just now and saw your response from a couple days ago.
Originally Posted by LandrovalBRG
UI for the string searches could use the same text box as is there now, but add perhaps checkboxes for "Find in: [ ]Filename [ ]Title"
I think it would be even more useful to me if I could also search by duration (range) and Title (partial string).
Let me give this some thought. Expanding on the range of what is searchable should be doable without overly complicating the UI.
Even if you don't add a range filter for duration, if you could make the Duration column sortable, it would be a big help. (Unlike with "Song Filename", "Parts", and "Folder", clicking "Duration" does not appear to re-sort the list. I realise that could be because some come from the file tags, but others may be calculated and not stored in your data structure in the same manner.)
Definitely not a process one would want to start accidentally with a large library. And, ideally, one would only ever run it on the whole directory once or twice. Should probably allow one to limit to the current filter view. (That way, you could check a single song or single directory.) (Filtering on filedate might be handy, but probably not, because the creation dates for the whole folder change every time you replace a collection from a new .zip.)
it would be handy if it could be set to recalculate the length of all songs (not just the ones with missing track durations) and flag the ones that are noted incorrectly by more than a couple seconds.
This is also very possible. Be forewarned that calculating song lengths is by far the most expensive thing LHH does, so doing a pass over every song in a big music folder would be time consuming.
Hmm. . .perhaps such a function does not really fit in well with TLHH, as that's a tool for making it easier to find songs, but the feature I suggested is for repairing them. Even so, TLHH already has most all of the capability that would be needed (cataloguing a library, calculating durations, one-click opening of file in text editor).
Maybe this is, instead, something to consider if you decide to add a tools menu. That way, it could start with a dialogue box for setting options such as: "Ignore differences less than [x] seconds", "[ ]Check all track titles for duration errors" (otherwise, perhaps it will only look for "%%song-duration tag" or the first title containing a time), "[ ]Find songs without time in track titles", or whatever.
I don't really know. Maybe just have it find the ones that do not match and list them so one may play and edit the files. Still, though, there should be some way for the UI to indicate both what the state duration is and the calculated one, but I know know where it would fit. (Having it in a separate report would work, even if less visually accessible.)
What are you envisioning seeing in the UI if LHH disagrees with a song's stated length?
If it is executed from the tool menu (instead of being a setting to modify the standard cataloguing behavior), perhaps the feature could start with a dialogue box for preferences, and finish with a "Scan Completed" pop-up showing a "1823 files scanned, 46 durations were missing, 5 have inconsistent track times" summary (maybe scrollable with detail?) with buttons for viewing/saving a detailed report as a text file. And, of course, the main window would be filtered to show the songs with errors.
Same question: what would this look like in the UI? Or perhaps it wouldn't show up in the UI at all, but in the export instead? I welcome your thoughts here.
Again, if you do decide to add some error-catching tools to LHH, another candidate would be one that scans for songs with duplicate part numbers (Songbook sometimes cannot play them), duplicate part titles (SongbookBB cannot tell which one is synched), duplicate %%part-name tags, mismatched song name within the part titles, etc.
I played with it some. LHHbt appears to stop reading the plugindata file when it encounters the Badger custom data. (If I had "write filter tags" enabled when I ran Songbooker, LHHbt only shows the first 113 files. If Songbooker builds the library catalogue without it enabled, LHHbt lists all 7132.)
I have not checked how TLHHobbit handles them, but SongbookBB, when used with Songbrowser and Songbooker, relies on special fields to display ensemble configuration options. . . . . . . . . .Does TLHH extract and store those when it builds and exports the library?
This is not a practice with which I am currently familiar.
I have not noticed any instances in which LHHbt, when indexing directly from the music directory, failed to catalogue an ABC file that included the Badger tags. That is really as expected, because the custom tags are each prefixed with a standard "N:" tag.
This is what Songbrowser writes to the ABC file (placing it after the top header block of %% tags, if any, and before the header for the first track):
Could you provide some example ABCs?
And this is what the song's record looks like in the .plugindata file if Songbooker is set to write filter tags:
N: TS 3, 41 61 71
N: TS 4, 41 51 61 71
N: TS 5, 11 41 51 61 71
N: TS 6, 11 21 41 51 61 71
N: TS 7, 11 21 41 51 61 62 71
N: TS 8, 11 12 21 41 51 61 62 71
N: TS 9, 11 12 21 31 41 51 61 62 71
N: TS 10, 11 12 21 31 41 51 61 62 71 91
N: Title: Flayed Alive
C: Barney the Dinosaur
N: Genre: Lullaby
["Filepath"] = "/ChildrenSongs/",
["Filename"] = "10-(Halg)FlayedAlive",
["Transcriber"] = "Halgoreth",
["Artist"] = "Barney the Dinosaur",
["Genre"] = "Lullaby",
["Partcounts"] = "CDEFGHIJ",
"EGI", "EFGI", "AEFGI", "ACEFGI", "ACEFGHI", "ABCEFGHI", "ABCDEFGHI", "ABCDEFGHIJ"
I seriously doubt it. I think the Brandy Badgerses came up with it on their own in order to address a set of very common points of frustration.
Also, is this something where the format is fairly standardized,
For tracking part setup variations, I doubt anyone else is doing it at all, other than by mixing a bunch of code letters into their part names. For things like "Genre" and "Artist" filter tags, those might be part of the larger ABC standard that LotRO does not use, but I have not looked.
or does everyone do it differently?
I'm not sure. I was thinking that if it recognised them, it could at least know to include them when exporting a new library cataloque. My thought had been a preference in which one can have a list of metatags that are to be written. However, I see from my example above, the ABC custom tags are not written as-is into the song record; they are translated into data values. That's not something I would expect LHH to do unless LHH itself had features that make use of the tags.
It is difficult to support such things in a tool if there is no consistency) If LHH was aware of such tags, what are you envisioning seeing?
Thus, at the least, I would like it if LHH could read from a songbook.plugin file containing such fields and know how to recognise and ignore them instead of aborting.
That's an interesting idea.
An optional popup (something like the lyrics button) that allows you to view the extra metadata?
Oh, one other thing. . .I would like the ability to copy a filename from the list (either drag-select and copy, or maybe hover and choose Copy from a right-click menu). And maybe folder name as well. It would be handy when for announcing to the rest of the band what file to queue (and where to find it) and also for writing out set lists. (Currently, if I find a song using TLHH and need to copy the filename, I navigate through my harddrive to find the file.) I would find that especially convenient for playing a song ingame after using TLHH to aid with my selection: just copy the name and paste it into Songbook's search box.