AT3 replay via Audiocodec.prx on 1.5
AT3 replay via Audiocodec.prx on 1.5
Here is the at3 replay (while waiting for the mp3 one), hopefully it'll work correctly on any other psp than mine this time ;D:
http://perso.orange.fr/franck.charlet/t ... Replay.zip
Any report welcome.
http://perso.orange.fr/franck.charlet/t ... Replay.zip
Any report welcome.
-
- Posts: 197
- Joined: Fri Jul 01, 2005 2:50 am
I forgot to include the prototypes for the audiocodec in the archive:
http://perso.orange.fr/franck.charlet/t ... oCodec.zip
http://perso.orange.fr/franck.charlet/t ... oCodec.zip
-
- Posts: 8
- Joined: Wed Mar 29, 2006 1:22 pm
It'll take slightly less user memory but more important if you want to use a non encrypted module you'll have to patch the kernel and of all the patches provided in the sdk only pspSdkInstallNoDeviceCheckPatch() (the only one i'm using here) is working on higher firmwares versions, all others just crash which is unfortunate because you'd probably need pspSdkInstallNoPlainModuleCheckPatch() to be able to run your own prx.I have a question that could be stupid since i'm a crapy coder but i would like to ask you why it would be better to use this directly in my code instead of using it as a prx module.
Nope, no particular reason.Also is there a reason why its named replayer and not player ? (of course yes:p)
great work on this...
just a note to anyone who plans on using the stubs in AT3.c to do playback in another app... the AT3_Datas_Start (hardcoded to 0x48 at the top for the sample .at3 file included in the distribution) changes depending on the specifics of the RIFF header of the file.
The easiest way to find the byte offset count to store in AT3_Datas_Start is to look for the 'data' tag in the RIFF header, go another four bytes after the tag, and that's the start of the actual data.
/Andrew
just a note to anyone who plans on using the stubs in AT3.c to do playback in another app... the AT3_Datas_Start (hardcoded to 0x48 at the top for the sample .at3 file included in the distribution) changes depending on the specifics of the RIFF header of the file.
The easiest way to find the byte offset count to store in AT3_Datas_Start is to look for the 'data' tag in the RIFF header, go another four bytes after the tag, and that's the start of the actual data.
/Andrew
I generated about 30 AT3 files with EAC PSP Edition, and almost all of them had offsets of 0x48, but I've seen a few with 0x44... turns out, that was the problem with the first file I was testing with and I spent a lot of time trying to figure out what was wrong. :)hitchhikr wrote:You're right but i haven't seen an at3 file with a different structure yet, so i took the short way, you could aswell parse the various headers until the data one is found (they have a id / length format like all riff files).
/Andrew