100% Orange Juice Music Files

[hugthebed2]

Attached is the smallest music .pak added with later DLC (the original game has a huge multi-chain .ogg file and there are many others) to the game "100% Orange Juice". If you want one that I think might be easier to mod, use one hosted here. Reading them is simple enough, as VLC or Audacity can be used. What I'm wondering is if it would be possible to actually mod the files or create files that the game could read so that I could mod the music to the game. Simply creating a chained .ogg file with "copy /b music1.ogg + music2.ogg music3.ogg" doesn't work as the second .ogg file (music2.ogg) doesn't load in-game and it leads to silence whenever it is supposed to come up. The most I've figured out is that modded music has to be smaller than the original filesize, but that's easy enough.

It may be hard to be able to understand or test without the game, but I've been looking and trying to figure this out for a while now and with my limited knowledge it's kind of difficult. If you need more examples/info or can point me in the right direction, it would be much appreciated.

[aluigi]

That pak is a raw container without information about the two archived oggs, of if there are information at the end they are not in clear-text.
It means you have an index file containing these information (maybe same name of that file but different extension?)
The problem of the chain you had seems related to it, the game expects a second ogg at offset 0x2f4a87 but doesn't find it.
What happens if the first chainged ogg is the original one and only the second is different (bigger than the original)?

[hugthebed2]

I'm not sure how I can extract the raw .ogg files using my current tools. Some old .ogg cutting files see it as a corrupt file and it doesn't work.

Perhaps the 63 megabyte original bgm.pak could help, as some more info is stored in it that the others don't have.

By the way, which file are you using?

[aluigi]

You can use this script to dump the ogg files:

Code: Select all

quickbmsver "0.7.6a"
get PAK_SIZE asize
math OFFSET = 0
    callfunction TEST 1
do
    math OFFSET = NEW_OFFSET
    goto NEXT_OFFSET
    getdstring DUMMY 10
    callfunction TEST 1
    xmath SIZE "NEW_OFFSET - OFFSET"
    log "" OFFSET SIZE
    math OFFSET = NEW_OFFSET
while OFFSET != PAK_SIZE

startfunction TEST
    math LAST_OFFSET = OFFSET
    findloc NEXT_OFFSET binary "\x01vorbis" 0 ""
    if NEXT_OFFSET == ""
        get NEW_OFFSET asize
    else
        goto NEXT_OFFSET
        findloc NEW_OFFSET binary "OggS" 0 "" LAST_OFFSET
    endif
endfunction

It's quite raw and lame but works

[hugthebed2]

The second music successfully plays but still has to be a smaller size then the original - it just loops as soon as it hits the byte it originally loops on, I'm guessing (this is observed on single file .paks that I've known how to mod because it's just one file). I should clarify - the music has to be smaller than the original to play fully without looping badly. Some music paks (the attached one in the original post is an example) have loop points I think, but they're not a priority at the moment.
So what's next, creating files that match up with the specific offset or is there something else to do?

[aluigi]

Your alternative is finding where are located the offset/size information, then modifying them and rebuilding the archives.

While the other pak of this game are just ZIP files (as Ekey said in your other topic), in this case they are raw containers so it means the information are stored somewhere else.
I found the list of files on the Internet and there is no trace of possible index files containing these information so I don't know where they are (prebuilt in the executable?).
In short, reimport the oggs if their size is minor/equal than the original or good luck

[hugthebed2]

Well, it's good enough for me right now. Thanks a lot, aluigi!