+- EmuNewz Network (https://www.emunewz.net/forum)
+-- Forum: PSP Emulation (https://www.emunewz.net/forum/forumdisplay.php?fid=191)
+--- Forum: JPCSP Official Forum (https://www.emunewz.net/forum/forumdisplay.php?fid=51)
+---- Forum: General discussion (https://www.emunewz.net/forum/forumdisplay.php?fid=57)
+---- Thread: Batch audio dumping (/showthread.php?tid=1277)
RE: Batch audio dumping - gid15 - 07-17-2010
The real file length can be found in the file itself: take the value of offset 4 and add 8 to the value
Code:
// RIFF file format:
// Offset 0: 'RIFF'
// Offset 4: file length - 8
// Offset 8: 'WAVE'
inputFileSize = mem.read32(inputBufferAddr + 4) + 8;BTW, Jpcsp was already computing some kind of CRC (AtracCode.java, line 62: Hash.getHashCodeFloatingMemory(0, address, length)) but this is based on the length passed to the sceAtracSetData() call. This length can be shorter than the real file length: the file is sent in small parts/chunks by the application. Also, the length used can differ from application to application and is not fixed. I don't know which length is the minimum length required by the PSP.
So you cannot be sure which length has to be used while computing the CRC outside of Jpcsp...
RE: Batch audio dumping - hyakki - 07-17-2010
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
RE: Batch audio dumping - Agent69 - 07-18-2010
My tool make files like:
Atrac-774373377x16843009x-240407618.at3
where
Atrac-(dec-location1)x(dec-location2)x(dec-location3). "dec location" - is signed 4bytes value.
All BMG files in criss core compressed in atrac3+. All other sounds in CC compressed in atrac3.
This formats has some differents ii "wav" headers.
In atrac3+ files, 4 bytes value on 0000003C offset ised for bitrate.
for example 01 00 28 2E:
01 00 - unknown
28 - stereo(24 - for mono)
2E - 64kbps(45 - for 96kbps).
4byte value on 00000004 offset == filesize-8
For atrac3 files, value on offset 60 (0000003C) is good, but if game has ~8000 at3 files....
For games, with all sound encoded in atrac3plus...
RE: Batch audio dumping - gid15 - 07-18-2010
According to the WAV file specification, the "fact" chunk gives the sample length:
http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html
length 4: Chunk ID: "fact"
length 4: Chunk size (minimum 4, it seems the PSP is using 8)
length 4: Number of Samples
This value seems to be different for files having the same length. But this chunk is not always located at the same place in the header. So the approach would be to search for the "fact" chunk and take the 32-bit "Number of Samples" following it.
Examples based on hyakki's post:
Atrac-0000C7CC-000420FF.at3 ("Number of Samples" 32-bit value at 3C)
Atrac-001DC5E4-006CD401.at3 ("Number of Samples" 32-bit value at 50)
Does this method work on CC?
RE: Batch audio dumping - Agent69 - 07-18-2010
(07-18-2010, 06:43 AM)gid15 Wrote: According to the WAV file specification, the "fact" chunk gives the sample length:nice idea.
http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html
length 4: Chunk ID: "fact"
length 4: Chunk size (minimum 4, it seems the PSP is using 8)
length 4: Number of Samples
This value seems to be different for files having the same length. But this chunk is not always located at the same place in the header. So the approach would be to search for the "fact" chunk and take the 32-bit "Number of Samples" following it.
Examples based on hyakki's post:
Atrac-0000C7CC-000420FF.at3 ("Number of Samples" 32-bit value at 3C)
Atrac-001DC5E4-006CD401.at3 ("Number of Samples" 32-bit value at 50)
Does this method work on CC?
Testing on CC:
Code:
###########################################_DUPS_#########################################
Atrac-17759x-1536617947x-1435890748.at3 ---> Atrac-17759.at3 CRC32: 683924957
Atrac-17759x1937771214x1380160688.at3 ---> Atrac-17759.at3 CRC32: 2570913708
Atrac-31634x-1584297101x541116802.at3 ---> Atrac-31634.at3 CRC32: 1543312282
Atrac-31634x-2020536832x1378449617.at3 ---> Atrac-31634.at3 CRC32: 870595897
Atrac-416427x-490584339x315634795.at3 ---> Atrac-416427.at3 CRC32: 4114682445
Atrac-416427x1428059941x1368478490.at3 ---> Atrac-416427.at3 CRC32: 2775905477
Atrac-74529x-2135713462x13224292.at3 ---> Atrac-74529.at3 CRC32: 1635851086
Atrac-74529x903750956x-2141885254.at3 ---> Atrac-74529.at3 CRC32: 1754929989RE: Batch audio dumping - gid15 - 07-18-2010
(07-18-2010, 07:11 AM)Agent69 Wrote: Testing on CC:Are these files where it did not work? Could you add a Dump/Screenshot of the header for these files so that we can look for a better method? The first 256 bytes should be enough.
Code:###########################################_DUPS_#########################################
Atrac-17759x-1536617947x-1435890748.at3 ---> Atrac-17759.at3 CRC32: 683924957
Atrac-17759x1937771214x1380160688.at3 ---> Atrac-17759.at3 CRC32: 2570913708
Atrac-31634x-1584297101x541116802.at3 ---> Atrac-31634.at3 CRC32: 1543312282
Atrac-31634x-2020536832x1378449617.at3 ---> Atrac-31634.at3 CRC32: 870595897
Atrac-416427x-490584339x315634795.at3 ---> Atrac-416427.at3 CRC32: 4114682445
Atrac-416427x1428059941x1368478490.at3 ---> Atrac-416427.at3 CRC32: 2775905477
Atrac-74529x-2135713462x13224292.at3 ---> Atrac-74529.at3 CRC32: 1635851086
Atrac-74529x903750956x-2141885254.at3 ---> Atrac-74529.at3 CRC32: 1754929989
Thanks!
RE: Batch audio dumping - hyakki - 07-18-2010
i updated my program to hex find fact and + 4 but some files still get the same value, but looks like data differs i could do that value too data +4
as it is now fact + 4
Atrac-00000E8C-0000005F.at3
here is one of the files
we should do two values for each
and also add data+4 it would look something like
Atrac-00000E8C-(5F45)(A091).at3
Atrac-00000E8C-(Fact+4)(Data+4).at3
^^^
this worked in my tests for crisis core, the highlighted files you can see the fact are the same but the data section is different
big files
ill try it on some more game see if it works
RE: Batch audio dumping - gid15 - 07-18-2010
Thanks for the research on CC!
I've added support in r1691 for the following decoded Atrac file names:
Code:
// Use the following alternate file name scheme:
// Atrac-SSSSSSSS-NNNNNNNN-DDDDDDDD.at3.decoded
// where SSSSSSSS is the file size in Hex
// NNNNNNNN is the number of samples in Hex found in the "fact" Chunk
// DDDDDDDD are the first 32-bit in Hex found in the "data" ChunkAtrac-001E8F24-006FB111-1DC0223A.at3.decoded
RE: Batch audio dumping - Orphis - 07-18-2010
Why don't we build a catalog containing a tree like structure differencing all the files from the first byte ?
RE: Batch audio dumping - hyakki - 07-18-2010
(07-18-2010, 10:06 AM)gid15 Wrote: Thanks for the research on CC!
I've added support in r1691 for the following decoded Atrac file names:
In the "big files" example from Hyakki, this should be:Code:// Use the following alternate file name scheme:
// Atrac-SSSSSSSS-NNNNNNNN-DDDDDDDD.at3.decoded
// where SSSSSSSS is the file size in Hex
// NNNNNNNN is the number of samples in Hex found in the "fact" Chunk
// DDDDDDDD are the first 32-bit in Hex found in the "data" Chunk
Atrac-001E8F24-006FB111-1DC0223A.at3.decoded
looks good, i'm going to do some more testing on other games and see if i can get any conflicts