[qt/qt/qtinterfaceframework-taglib]: Summary of bulk changes made

Git repository change summary for qt/qt/qtinterfaceframework-taglib
Pushed by mirror-service into branch 'upstream/master'.
Changed from 77f547760995217dd5fa321b162fa9149272989d to 3ace0483c0d7a2a4c1dbf9277274f0e733530504
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 766471a5a4794370b3cc45f0113ec18f8715a13d by GitHub (on behalf of Acts1631) on 14/08/2026 at 04:07..
APE: limit parsed tag item count (#1411)

An APEv2 footer controls the number of parsed items without a bound.
A small crafted tag can therefore allocate a large item map and terminate
a memory-constrained application.

Stop parsing after 50,000 items. This matches existing parser count limits
and preserves entries parsed before the limit.
https://invent.kde.org/qt/qt/qtinterfaceframework-taglib/-/commit/766471a5a4794370b3cc45f0113ec18f8715a13d

Git commit 3ace0483c0d7a2a4c1dbf9277274f0e733530504 by GitHub (on behalf of Ryan Francesconi) on 14/08/2026 at 04:47..
RIFF: support RF64 and BW64 (#1412)

RF64 and BW64 are the long forms of WAVE, used past 4 GB: each 32-bit
size field holds a 0xffffffff sentinel and the real sizes live in a
leading ds64 chunk. RIFF::WAV::File::isSupported() rejected them, but
FileRef reaches the class by extension for any .wav and RIFF::File::read()
never inspected the magic, so these files opened as valid.

updateGlobalSize() then wrote a real 32-bit total over the sentinel at
offset 4. Readers stop consulting ds64 once that field holds a number, so
a 4.8 GB file measured 0.005958 sec and 1144 audio bytes after a tag save
that returned true. Below 4 GB the tags were lost instead: the appended
LIST landed inside the region read() had clamped the sentinel data chunk
to, and a re-read found no properties.

Worse, the append offset is last.offset + last.size with size truncated to
0xffffffff, so on a long file the new chunk was spliced into the middle of
the audio — measured at offset 4294971392 on that same file, 4 GiB past
the data chunk's start, displacing everything after it.

Accept both magics, take the riff and data sizes from ds64, and write the
sentinel back on save. Writing it unconditionally is what the format
requires and also repairs a file an earlier version damaged: the same
4.8 GB file, clobbered and then saved through this path, read back at
25000.000000 sec and 4,800,000,000 bytes.

The ds64 table of additional oversized chunks is not parsed — the data
chunk has its own dedicated field and is the only one that is ever large —
so any chunk listed there stays on the clamping path added in #1329, which
this leaves untouched.

Chunk::size becomes offset_t so the append offset is computed correctly.
The struct is file-scope in rifffile.cpp and FilePrivate is only
forward-declared, so no protected signature changes and no ABI break.
chunkDataSize() still returns unsigned int, saturating rather than
truncating; a new chunkDataSize64() carries the real value to
WAV::Properties, which otherwise reports 0 s for a long file.

AIFF is big-endian and has no long form, so RIFF::File's only other
subclass cannot reach the new branch.

tests/data/rf64.wav is 9,680 bytes and built by construction, not by an
encoder; Core Audio reads it as RF64 at 0.050000 sec. The sentinels behave
identically at any size, so a small fixture covers the detection failure,
the sentinel overwrite and the repair.
https://invent.kde.org/qt/qt/qtinterfaceframework-taglib/-/commit/3ace0483c0d7a2a4c1dbf9277274f0e733530504