Otherwise the `--output-files` option of the tag editor will be ignored
when editing an MP4 file and no rewrite is required.
Note that the condition is already this way in `MediaFileInfo::makeMp3File()`
and `MatroskaContainer::internalMakeFile()`.
When there's no mapping for the specified known field, `fieldId()` returns
an invalid field ID. It should not be passed to `setValues()` as we would
otherwise attempt to create an invalid field.
The bytes skipped while searching for MP3 frames should not be used as
container offset. The container offset should just the offset after the
first ID3v2 tag (or zero if there are no tags).
* This makes it harder to use the library wrongly and does not lead to
worse performance as character set conversions are only done as needed.
* That's actually already done by serializers for most tag formats. This
change ensures serializers for Matroska and Vorbis tag fields do this as
well.
* Update documentation accordingly.
* Allow one to get a `Popularity` where `.rating` is always between 1 and 5
via `TagValue::toScaledPopularity()` (or a "raw" scale by specifying the
corresponding tag format)
* Allow one to assign a `Popularity` with `.scale = TagType::Unspecified`
and `.rating` between 1 and 5 (or a "raw" scale by specifying the
corresponding tag format). It will then be converted internally to
the required scale (whatever the tag format internally uses)
* Ensure all tag formats with popularity/rating field use
`TagValue::toScaledPopularity()` internally when a `Popularity`
object is assigned
* Ensure all tag formats with popularity/rating field store the rating as
popularity object to preserve the scaling information
* Keep passing raw strings around working
* `TagValue::toString()` still does *no* scaling
* `TagValue::toScaledPopularity()` does *no* scaling for text values
and instead just assigns the specified scale
* See https://github.com/Martchus/tagparser/issues/23
This would allow implementing a way to convert between different scales and
which in turn would allow the UI to provide an editor with a generic scale
(e.g. stars) instead of only allowing to edit raw values as string.
This also make it assume that a single number is meant to be the rating
(instead of the user). That should make editing the rating a bit more
straight forward (if one doesn't care about the user and play counter).
* Propose the usage of the popularity type in general for the rating field
so GUIs can show an appropriate UI element
* Do not just propose the popularity type for ID3v2 tags so a uniform UI
element can be shown accross tag formats; and API to convert from a
uniform scale is still TODO
Martchus