[
https://issues.apache.org/jira/browse/TIKA-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095548#comment-18095548
]
ASF GitHub Bot commented on TIKA-4779:
--------------------------------------
dschmidt opened a new pull request, #2947:
URL: https://github.com/apache/tika/pull/2947
JIRA: https://issues.apache.org/jira/browse/TIKA-4779
The total number of tracks and discs is present in all common audio
containers but was dropped: the MP4 parser read the second value of the
`trkn`/`disk` atoms and discarded it, ID3 TRCK/TPOS "n/total" values were
passed through unsplit, and the Vorbis TRACKTOTAL/DISCTOTAL comments were
not mapped.
XMPDM has no property for the totals and cannot be extended, so this adds
a Tika-owned `org.apache.tika.metadata.Audio` interface, following the
pattern of `Geographic` and the Google properties from TIKA-4775:
* `audio:track-count` / `audio:disc-count`: the totals, from the MP4
atoms, the "n/total" form, and the Vorbis TRACKTOTAL/TOTALTRACKS/
DISCTOTAL/TOTALDISCS comments (explicit comments win over the combined
form).
* `audio:raw-track-number` / `audio:raw-disc-number`: the value exactly
as tagged.
With the raw value preserved, `xmpDM:trackNumber` and `xmpDM:discNumber`
now only receive clean positive integers. They are declared as Integer
properties but previously received the raw tag value, including "3/12"
and non-numeric forms like vinyl "A1", which broke typed consumers. This
is a deliberate output change that should land before 4.0; nothing is
lost, the original value stays available under the raw properties. The
combined form is parsed by a small `NumberAndTotal` value class, same
shape as the recently added `ISO6709` parser. The Ogg path also gains
the previously unmapped DISCNUMBER comment.
This is part 1 of 2 for TIKA-4779; bitrate, VBR detection and DRM
detection need actual parser work (Xing/VBRI headers, MP4 `sinf`) and
will come separately.
Testing: the existing `testMP4.m4a` fixture already carries the totals
(track 1 of 42, disc 6 of 12, previously discarded); the ID3v2.4 fixture
gains a TRCK "3/12" frame (25 bytes appended to the tag, audio bytes
untouched); `NumberAndTotalTest` covers the parse edge cases and the
parser tests assert typed, count and raw values including degenerate
forms.
One process question: this PR deliberately changes metadata output shape
(xmpDM:trackNumber/discNumber becoming strictly integer), and 4.0 is
accumulating a few more of those (e.g. the xmp-raw rename in TIKA-4775).
Should such output changes be recorded in the BREAKING CHANGES section of
CHANGES.txt as a matter of course? Happy to add an entry here, I just did
not want to unilaterally open a new unreleased section in the file.
> 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)
