[
https://issues.apache.org/jira/browse/TIKA-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095990#comment-18095990
]
ASF GitHub Bot commented on TIKA-4779:
--------------------------------------
dschmidt commented on PR #2947:
URL: https://github.com/apache/tika/pull/2947#issuecomment-4962169595
Amazing, thanks! This has been bugging me for so incredibly long but I never
found the motivation to work on it ... Thanks, Claude, I guess :D
> 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)
