Karosa
12-10-2003, 07:40 PM
Okay.. Here it goes..
We have a container file (bgm.arc) which contains audio files merged to it.
(It's not packed with the old ARC archiver, it just has the same extension)
It has a catalog section, that keeps track of all files in the
container file, using 6
numbers.. :roll: BUT I have no info on how this works..
This game stores the audio in this file uncompressed, so it's just a container,
I could easily split up the file to get the audio, but then again, what I want
to write will be a universal code, that automatically splits the files, because while I
possibly can split up the BGM file successfully (even a blind can spot OGG Vorbis
headers) I will surely fail if I try to do this with the scripts (Which are
encoded, if i'm not mistaken, and they don't have a header that I can look for) (another file with same format)
So.. What we have inside is:
Audio file 1 starting at byte: 288 (Hexa:120)
Audio file 2 starting at byte: 754 324 (Hexa:B8294)
Audio file 3 starting at byte: 1 782 750 (Hexa:1B33DE)
*******************
First Catalog Entry (We need to calculate 288 from the below numbers somehow)
*******************
BGM001 116 129 11 32 1 0
In hex: 74 81 B 20 1 0
-----------------------------------------
Well, let's experiment:
116+129+11 = 256
32*1+0 = 32
256+32 = 288
********************
Second Catalog Entry (We need to calculate 754324, somehow)
********************
BGM002 74 177 15 148 130 11
In Hex: 4A B1 0F 94 82 0B
-------------------------------------------------
Let's try the routine that worked the first time:
74+177+15 = 266 (Hex:10A)
148*130+11 = 19251 (Hex:4B33)
(148+130)*11 = 3058
266*3058 = 813428
19251+266 is too low
19251*266 is too high
We can't calculate it this way..
Let's look for something that still solves the first catalog entry, but is
different. But then again, maybe it was just a mistake that the first worked.
Maybe These numbers store beginning and end of the file in some way, not just
the beginning position.. I don't know..
*******************
Third Catalog Entry
*******************
BGM003 182 240 12 222 51 27
In Hex: B6 F0 0C DE 33 1B
----------------------------------------------
222+51 * 27 = 7371
The objective is to find a calculation that works for all entries, or a
calculation sequence that can be defined to work for all entries.
ANY help whould be greatly appreciated.
--
Karosa Alabaster
We have a container file (bgm.arc) which contains audio files merged to it.
(It's not packed with the old ARC archiver, it just has the same extension)
It has a catalog section, that keeps track of all files in the
container file, using 6
numbers.. :roll: BUT I have no info on how this works..
This game stores the audio in this file uncompressed, so it's just a container,
I could easily split up the file to get the audio, but then again, what I want
to write will be a universal code, that automatically splits the files, because while I
possibly can split up the BGM file successfully (even a blind can spot OGG Vorbis
headers) I will surely fail if I try to do this with the scripts (Which are
encoded, if i'm not mistaken, and they don't have a header that I can look for) (another file with same format)
So.. What we have inside is:
Audio file 1 starting at byte: 288 (Hexa:120)
Audio file 2 starting at byte: 754 324 (Hexa:B8294)
Audio file 3 starting at byte: 1 782 750 (Hexa:1B33DE)
*******************
First Catalog Entry (We need to calculate 288 from the below numbers somehow)
*******************
BGM001 116 129 11 32 1 0
In hex: 74 81 B 20 1 0
-----------------------------------------
Well, let's experiment:
116+129+11 = 256
32*1+0 = 32
256+32 = 288
********************
Second Catalog Entry (We need to calculate 754324, somehow)
********************
BGM002 74 177 15 148 130 11
In Hex: 4A B1 0F 94 82 0B
-------------------------------------------------
Let's try the routine that worked the first time:
74+177+15 = 266 (Hex:10A)
148*130+11 = 19251 (Hex:4B33)
(148+130)*11 = 3058
266*3058 = 813428
19251+266 is too low
19251*266 is too high
We can't calculate it this way..
Let's look for something that still solves the first catalog entry, but is
different. But then again, maybe it was just a mistake that the first worked.
Maybe These numbers store beginning and end of the file in some way, not just
the beginning position.. I don't know..
*******************
Third Catalog Entry
*******************
BGM003 182 240 12 222 51 27
In Hex: B6 F0 0C DE 33 1B
----------------------------------------------
222+51 * 27 = 7371
The objective is to find a calculation that works for all entries, or a
calculation sequence that can be defined to work for all entries.
ANY help whould be greatly appreciated.
--
Karosa Alabaster