me_wrapper.prx's dispatch table gives 0x1004 a handler that returns -1, so it
is plumbed through avcodec.prx but not implemented on 6.61 - not the real
sixth codec the earlier comment claimed.
Also records the bound that matters for the Atrac3 frame-size question: the ME
is handed a context whose first 0x68 bytes are the only ones made coherent, so
nothing outside that can be reaching it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Atrac3 no longer hardcodes 384 bytes per frame. The context only carries the
joint-stereo flag for Atrac3 - libatrac3plus.prx writes nothing else there, and
AtracCtx2 already mirrors that - but exactly one of the five supported frame
sizes is joint stereo (66kbps stereo, 0xC0 bytes), so that flag identifies it
on its own. Everything else keeps the old 132kbps assumption, now via the
existing at3HeaderMap rather than a magic number.
MP3 was passing srcBytesRead as the input length, which is an output field
holding what the *previous* call consumed - zero on the first frame. Use the
bound at 0x28 instead, which is what the hardware uses and which the caller
guarantees is readable at inBuf, since it does a cache writeback over exactly
that range. Channels and sample rate now come from the context's channel
configuration and its version/sample-rate index pair, using the same table
avcodec.prx indexes, rather than being assumed stereo 44100.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The first 0x28 bytes of the context are the same for every codec - and for
sceVideocodec's own context, which annotates the same fields - so this is one
ME codec-context ABI. Everything after that is per-codec, with each library
writing a different set of fields, so it becomes a union.
Also documents that 0x28 is not a frame size for MP3: the hardware only uses it as a
cache-writeback length, so it is an upper bound - which is why the firmware
never bothers computing an exact one anywhere.
Adds codec id 0x1004, which the hardware accepts and handles much like MP3.
Unidentified, but the range check really does accept six codecs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Rename LogType to Log
* Explicitly use the Log:: enum when logging. Allows for autocomplete when editing.
* Mac/ARM64 buildfix
* Do the same with the hle result log macros
* Rename the log names to mixed case while at it.
* iOS buildfix
* Qt buildfix attempt, ARM32 buildfix
