I'm not sure what agent69's tool does but i made a temporary program that can make the file like
Atrac-0009E394-000000A9.at3
where
atrac-hex(sizeinBytes)-hex-location
where hex-location is the hexvalue at some location in the file (i used 2048bytes into the file in above example) but i can make it anything
i compared a few same size files and it appears offset 0000003C are differn't
so if i made my program use 3C (60bytes) the files would appear as
Atrac-0000154C-0000008A.at3
Atrac-0000154C-000000C0.at3
or i could do two values
ie
Atrac-0000154C-00008A6A.at3
Atrac-0000154C-0000C069.at3
here is a quick screen shot
filenames before convert (can be any filename as long as it ends with .at3)
after run using the 0000003C offset
i tested this with all crisis core files (1260 files) and still about 4 files come out with the same filename even when using two values, so its possible some files have the same runtime and filesize, however i was thinking why not use two values one of the 0000003C offset and another one at like 0000006C, anyways im open to suggestions.
Update:
here is something that worked successfully renamed all the crisis core files, Jpcsp would need to read the offset in the file at 3C and 6C (or whatever values you want to use).
[name]-[FileSizeinhex]-[00FF[single hex value at 0000003C],005B[single hex Value at 0000006C], the 00's I added in but i can make them values if needed since im only reading one hexchar but i can make it two for each offset.
Atrac -0000C7CC - 00FF005B.at3
but i noticed on some of the big files dont change the value at 3C or 6C (the bgm files in crisis core are different format then the smaller voice audio) the offset its like you said on these files 00000004-00000005 and 0000001C-0000001D (values in red are what change in these files) (Yellow is what my program is using, red is what the big files change)
even though it worked on 1300 files in crisis core, would it work in other games or other audio formats?
I think it would be better to read 4 hexbytes at a high value after 500 or 1000 bytes into the file since it should be past the header and the data should be more random there and the chances of having the same values at that point is unlikely
Atrac-0009E394-000000A9.at3
where
atrac-hex(sizeinBytes)-hex-location
where hex-location is the hexvalue at some location in the file (i used 2048bytes into the file in above example) but i can make it anything
i compared a few same size files and it appears offset 0000003C are differn't
so if i made my program use 3C (60bytes) the files would appear as
Atrac-0000154C-0000008A.at3
Atrac-0000154C-000000C0.at3
or i could do two values
ie
Atrac-0000154C-00008A6A.at3
Atrac-0000154C-0000C069.at3
here is a quick screen shot
filenames before convert (can be any filename as long as it ends with .at3)
after run using the 0000003C offset
i tested this with all crisis core files (1260 files) and still about 4 files come out with the same filename even when using two values, so its possible some files have the same runtime and filesize, however i was thinking why not use two values one of the 0000003C offset and another one at like 0000006C, anyways im open to suggestions.
Update:
here is something that worked successfully renamed all the crisis core files, Jpcsp would need to read the offset in the file at 3C and 6C (or whatever values you want to use).
[name]-[FileSizeinhex]-[00FF[single hex value at 0000003C],005B[single hex Value at 0000006C], the 00's I added in but i can make them values if needed since im only reading one hexchar but i can make it two for each offset.
Atrac -0000C7CC - 00FF005B.at3
but i noticed on some of the big files dont change the value at 3C or 6C (the bgm files in crisis core are different format then the smaller voice audio) the offset its like you said on these files 00000004-00000005 and 0000001C-0000001D (values in red are what change in these files) (Yellow is what my program is using, red is what the big files change)
even though it worked on 1300 files in crisis core, would it work in other games or other audio formats?
I think it would be better to read 4 hexbytes at a high value after 500 or 1000 bytes into the file since it should be past the header and the data should be more random there and the chances of having the same values at that point is unlikely
Try Out JPCSP Launcher v1.8.0.4 | How to post a log