Does not work on Super Mario Maker II bars

[ultrasound1372]

Via some cross-checking I've done with this program, a BotW QuickBMS script that produces correct file names but invalid data, and VGMStream's bwav metadata, I've come to the following conclusions for this game at least.

• at offset 0x04 of the file in total is a u32 which notes the size of the bars file, including the magic number. This should be exactly the same as the size of the file if extracted correctly. If it isn't, you might have the wrong endianness.
• at offset 0x08 is the BOM in two bytes, little endian if 0xFFFE, big endian if 0xFEFF. For the switch, this is supposedly always little endian.
• At offset 0x0C is a u32 noting the number of individual files in this container (filecount).
• After this is a sequence of filecount 32-bit values. The QuickBMS script calls this HASH, but does not use that variable further.
• After this is a sequence of filecount pairs of u32s (headerstart, filestart) which are absolute offsets to an AMTA header and its corresponding BWAV file respectively.
• At offset headerstart is the AMTA tag as you would expect, followed immediately by a two-byte BOM as before.
• At 0x12 bytes from after the BOM, or 0x18 from the beginning of the AMTA header, is a u32 telling the relative offset of the name, (strgstart).
• At offset headerstart + strgstart is a pair of u32s followed by the name as a null-terminated string. The first one I have no idea about, possibly checksum, while the second is the length of the string, including the null byte. You could get the string either by using this length and the offset next to it or by seeking 8 more bytes from the beginning and going for a null.

It seems the trick you're doing to just subtract offsets of chained BWAV files is the most effective way to get their length, as I couldn't find any other way to get it, unless the AMTA header has it buried as one of the u32s that follow it. But this code is completely incapable of getting the file names from these files, while the QuickBMS script gets the names but botches finding the length and produces 64K or 0B files, due to the assumption that a BWAV file contains a size. I believe these are AMTA v4 files. While I'm not familiar with the overall structure of AMTA, the presence of a 0x04 byte at headerstart + 7 suggests this. I personally haven't seen AMTA v5 files. If necessary I can send you one for you to examine, and possibly derive more info than I have.

[ultrasound1372]

Follow-up: The length value appears to not quite be correct, it falls short in some filenames. The manually searching for null appears to be the best way to obtain the name.