[
https://issues.apache.org/jira/browse/TIKA-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095545#comment-18095545
]
Dominik Schmidt commented on TIKA-4779:
---------------------------------------
Regarding the naming question: the xmp refactor in [PR
#2946|https://github.com/apache/tika/pull/2946] settles it nicely for me.
It introduces a small Tika-owned interface (Google.java) with typed properties
for keys that have no home in an external schema, and that is exactly our
situation here, since XMPDM cannot be extended.
So I'd add an org.apache.tika.metadata.Audio interface along these lines:
{code:java}
Property TRACK_COUNT = Property.internalInteger("audio:track-count");
Property DISC_COUNT = Property.internalInteger("audio:disc-count");
Property BITRATE = Property.internalInteger("audio:bitrate"); // bits per second
Property IS_VARIABLE_BITRATE =
Property.internalBoolean("audio:is-variable-bitrate");
Property HAS_DRM = Property.internalBoolean("audio:has-drm");
{code}
Prefix and kebab-case follow the newer Tika-owned properties
(\{{mapi:is-flagged}}, \{{msoffice:excel:has-hidden-sheets}}). I'd deliberately
not use \{{xmpDM:fileDataRate}} for the bitrate, a Rational in MB/s is an
awkward fit for audio.
I'd split the work in two: a first PR with the interface, track-count and
disc-count plus the "n/total" normalization of xmpDM:trackNumber/discNumber
(that value shape change should really land before 4.0 (!!!)), and a second one
for bitrate/VBR/DRM, since those need actual parser work (Xing/VBRI headers,
MP4 sinf detection).
Happy to adjust the names if anyone has better ideas?
> Audio parsers do not expose total track count (trackCount)
> ----------------------------------------------------------
>
> Key: TIKA-4779
> URL: https://issues.apache.org/jira/browse/TIKA-4779
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> Tika does not expose the "total number of tracks on the album" for audio
> files, even though all common audio container formats carry this information
> and the parsers partially already read it.
> *Background*
> Audio metadata is mapped onto the XMP Dynamic Media schema ({{{}XMPDM{}}}),
> which defines {{xmpDM:trackNumber}} but has no property for the total track
> count. Since XMPDM cannot be extended upstream, Tika never picked up the
> value - but the information is present in the files:
> * *MP4/M4A:* the {{trkn}} atom contains two integers, track number and total
> track count. {{TikaUserDataBox.processIList()}} reads *both* values but only
> sets the first one and silently discards the second ({{{}numB{}}} is read and
> never used):
> {code:java}
> } else if ("trkn".equals(fieldName)) {
> if (toRead == 8) {
> long numA = reader.getUInt32();
> long numB = reader.getUInt32(); // total track count — discarded
> metadata.set(XMPDM.TRACK_NUMBER, (int)numA);
> }
> {code}
> (tika-parser-audiovideo-module,
> {{{}org.apache.tika.parser.mp4.boxes.TikaUserDataBox{}}})
> * *MP3/ID3v2:* the {{TRCK}} frame commonly has the form {{{}"3/12"{}}}. All
> ID3 handlers
> ({{{}ID3v22Handler{}}}/{{{}ID3v23Handler{}}}/{{{}ID3v24Handler{}}}) pass the
> raw string through, so the total ends up *embedded* in {{xmpDM:trackNumber}}
> as {{"3/12"}} — even though that property is declared
> {{{}externalInteger{}}}. The same applies to {{TPOS}} → {{xmpDM:discNumber}}
> (see {{{}Mp3ParserTest{}}}, which asserts {{"1/1"}} for discNumber). So for
> MP3 the value leaks through unstructured instead of being exposed as a proper
> field.
> * *OGG/FLAC:* the Vorbis comment {{TRACKTOTAL}} is not mapped at all
> ({{{}OggAudioParser{}}} only sets {{{}XMPDM.TRACK_NUMBER{}}}).
> *Proposal*
> # Introduce a property for the total track count. Since {{xmpDM}} has no
> such field, either a Tika-owned property (e.g. in a {{tika:}} namespace) or a
> documented non-standard extension.
> # Populate it in the three parsers: MP4 ({{{}numB{}}} from {{{}trkn{}}}),
> MP3 (split {{TRCK}} on {{{}"/"{}}}), OGG/FLAC ({{{}TRACKTOTAL{}}}).
> # While at it, consider normalizing {{xmpDM:trackNumber}} /
> {{xmpDM:discNumber}} to the plain number so the values actually conform to
> their declared integer type (possibly keeping the raw value elsewhere for
> backwards compatibility). Anyhow before 4.0.0 is about as good as timing can
> be for a breaking change
> The analogous question applies to the disc count ({{{}TPOS{}}} total, MP4
> {{disk}} atom second value).
> Willing to work on this, just let me know, how you would like to have it
> solved. Especially the property names.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
