Batch audio dumping

[gid15]

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;

Does this value differ from the file length generated by the extract tool? I'm wondering how compressed audio data can generate so many file with the same length. They are probably padded at the end.

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...

[hyakki]

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

[Agent69]

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...

[gid15]

According to the WAV file specification, the "fact" chunk gives the sample length:
http://www-mmsp.ece.mcgill.ca/Documents/.../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?

[Agent69]

According to the WAV file specification, the "fact" chunk gives the sample length:
http://www-mmsp.ece.mcgill.ca/Documents/.../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?

nice idea.
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: 1754929989

good result for ~1300 files.

[gid15]

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: 1754929989

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.

Thanks!

[hyakki]

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

[gid15]

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" Chunk

In the "big files" example from Hyakki, this should be:
Atrac-001E8F24-006FB111-1DC0223A.at3.decoded

[Orphis]

Why don't we build a catalog containing a tree like structure differencing all the files from the first byte ?

[hyakki]

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" Chunk

In the "big files" example from Hyakki, this should be:
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