Kid3-cli config help

Help
1

Hi. I use kid3 extensively, and have recently begun using kid3-cli to script some tasks. I’m struggling with track numbers, though. I like my numbers to be zero-padded, and have no problem with this in the GUI by setting the track number digits option to 2.

kid3-cli has been another story. I struggled for hours as I could find no way to make this work via CLI args, and it didn’t respect my kid3 config. I finally found this revelatory post:
(I can’t include links in my post, so the thread title is “Kid3-cli and timestamp preservation”)

I see that kid3-cli uses a different config file. I’ve finally been able to piece together enough things to get something working, but I’d like to understand things a little better as this seems much more difficult than it should be and I’m not sure if I’m just missing something obvious.

Is there any documentation that discusses the CLI config file at all? or any hints that it even exists besides that forum post? “Chapter 4. kid3-cli” of the kid3 manual doesn’t seem to say anything about it, unless I’m blind.

Similarly, is there any way to create or export a default config? I can’t find any way to do that, but tuxEgangelist’s comment about it creating it’s config after running kid3-cli -c "config File.preserveTime true" gave me something I can work with in a roundabout way.

By editing:
[Tags]
TrackNumberDigits=2

I seem to have it doing what I want, which is great. But how do the config commands actually map to the file? It says Tags doesn’t exist:

$ kid3-cli -c “config Tags.TrackNumberDigits 2”
Tags does not exist

I noticed in the other thread that it specified File.preserveTime, despite the option existing in the Files section. No luck with that either, though:

$ kid3-cli -c “config Tag.TrackNumberDigits 2”
TrackNumberDigits does not exist

But closer as it at least seems to recognize Tag now. But how do I configure this actual parameter? I’d like to include this in my script so it’s not dependent upon a preexisting configuration.

That last question is really the main thing I need to know at this point, but I’m asking the additional questions because I’d like to understand this better, and also would hope anyone else struggling with this may find this in the future and get some help. or… if I’m just being exceptionally dense here, would really love someone to point out what I’m missing. :slight_smile:

Thanks!

2

after poking at this some more, I realized that the preserve time parameter starts with a lowercase letter when configured via CLI:

File.preserveTime

I tried doing the same with track number digits, and sure enough it worked!

kid3-cli -c “config Tag.trackNumberDigits 2”

So that’s great - I have this working exactly like I need now. But, it’s really unintuitive that:

  • kde-cli users a different, undocumented configuration file
  • the config command uses a singular form of section titles whereas the file uses plural
  • the config command starts configuration parameters with lowercase whereas the file uses uppercase

I know ufleisch said it uses a different config file because it’s based on qt rather than kde, so I’m sure there are valid reasons for all of these changes, but I’d love to see better documentation on this.

And just to be clear, I really don’t mean for this to come across as venting or complaining. I love kid3 - have used it heavily for many, many years and am very appreciative all the work Urs has put into it. Just hit a weird and unexpected wall on this.

3

Sorry for the trouble. The kid3-cli config is described in the handbook Chapter 4. kid3-cli . The different configuration options are not listed in the handbook because they can be found from within kid3-cli, if you just type config, you get all config groups, with the group (e.g. config Tag), you will see all options, e.g. trackNumberDigits. Before I added the config option, editing the config file was the only option, but now this is no longer needed and can be considered an internal implementation detail which does not have to match the config API. The naming and the lower case are consistent with the other APIs (C++ and QML). Considering the configuration file: Actually the Qt configuration file is the standard as it is used by kid3-qt on Linux and kid3 on Windows, macOS, and Android, the KDE configuration is the one which is the exception, but I see that this can be confusing. The configuration files are documented in Configuration . Probably the reason for KDE using their own format is historical. Also Kid3 has its history and some things have grown over the years and could surely be more intuitive. But I am glad that you nevertheless love it and that you have found the solution.

4

thanks for the feedback. I read that kide-cli page numerous times, but did indeed miss the Configuration page. Good to know for future reference in case I forget the exact path. And do appreciate the extra context.

Btw, I found what appears to be a bug:

$ id3info 02-Visions\ of\ Hjollder\ \(Intro\ Movie\).mp3 | grep TRCK
=== TRCK (Track number/Position in set): 02

$ kid3-cli -c "tag 2" -c "totag '%{genre}/%{artist}/%{album}/%{tracknumber}-%{title}'" -c "to23" -c "get all" -c "revert" 02-Visions\ of\ Hjollder\ \(Intro\ Movie\).mp3  | grep ^*
* Track Number           02

The track number is stored (or at least displays every place I view it) as two digits, but running kid3 against it detects that it needs to be “changed” to 2 digits. I have track number digits set to 2. If I go ahead and apply that change (lose the revert), it’ll do the same if I run it again. I also see the same behavior in the gui - will running from file to Tag two will always detect the track number as changed and re-write it.

I suspect it has something to do with MP3/ID3 generally being much more limited in its fields and something not linking the zero, but it does seem to be stored properly, and even displays properly in kid3 gui, so I don’t know why it keeps thinking it needs to be changed.

Sorry for going off-topic here. I was going to open a bug report, but it actually says to bring it up here first if uncertain, and this may be a known limitation.

5

Thanks for the report. I can reproduce it. The problem is that the setting of tag frames from a file name is in a component which is independent of the tag format (i.e. it is used for Tag 1, 2, 3 and thus for any of the supported tags) whereas the configuration options Tag.enableTotalNumberOfTracks and Tag.trackNumberDigits are specific for “Tag 2” therefore the code in TaggedFile::getTagsFromFilename() does not respect any of these options such as ignoring changes to leading zeros. It will explicitly remove leading zeros when setting the track number. Probably this is the desired behavior for some users (including me), but in your case it is annoying because you get “02” from the file name, it is converted to 2, consequently a change in the value is detected before the 2 is again converted to “02” by ID3v2 handling code calling TaggedFile::formatTrackNumberIfEnabled().

The good news is that there seems to be a workaround: The removal of leading zeros in TaggedFile::getTagsFromFilename() is only done if the filename-to-tag format is not using custom regular expression patterns, so you could try a format like

.*/%{genre}([^/]+)/%{artist}([^/]+)/%{album}([^/]+)/%{tracknumber}(\d+)-%{title}(.+)

to avoid it.