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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
