[
https://issues.apache.org/jira/browse/TIKA-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095086#comment-18095086
]
Dominik Schmidt commented on TIKA-4779:
---------------------------------------
*Additional context*
Some real-world context on why this matters beyond spec-completeness:
[OpenCloud|https://github.com/opencloud-eu/opencloud] re-implements the MS
Graph {{audio}} facet ([Microsoft
documentation|https://learn.microsoft.com/en-us/graph/api/resources/audio?view=graph-rest-1.0])
as part of the [Libre Graph
API|https://github.com/opencloud-eu/libre-graph-api] and populates it from Tika
output in its search service
([tika.go|https://github.com/opencloud-eu/opencloud/blob/main/services/search/pkg/content/tika.go]).
Besides {{{}trackCount{}}}/{{{}discCount{}}}, the facet has more fields whose
values exist in the files but have no xmpDM property, so exposing them would
require Tika-owned property names as well:
* {{isVariableBitrate}} - MP3 Xing/VBRI headers, Vorbis min/nominal/max
bitrates
* {{hasDrm}} - e.g. protected MP4 sample entries ({{{}drms{}}}/{{{}drmi{}}})
* {{bitrate}} - arguably; {{xmpDM:fileDataRate}} exists but is defined as MB/s
file data rate, not audio bitrate
It might make sense to settle on a naming scheme for these together with
trackCount/discCount rather than one-off. I'm not saying we need to provide the
same data types, but something I can derive the facet property value from would
be great.
> 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).
> 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 name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
