terminate called after throwing an instance of 'boost::filesystem::filesystem_error'

[Ender97]

It seems like in some .bars files, there are characters that aren't recognized by the code. I am able to put the .bars files into a hex editor and manually extract some bwav files, but when I point the code at these files, it aborts. Here's the output. (My username has been replaced with [me] where applicable.)

Processing BARS file /media/[me]/5666B7CA66B7A95F/Users/[me]/Desktop/SWITCH/Extracted Files/Romfs/Sound/Resource/Bgm_Base.bars size: 5273884

Found all BWAV files. Total count: 682. Writing bwav files to /media/[me]/Seagate BUP/ACNH Sounds 2/
Output subdirectory: Bgm_Base/
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::status: Invalid or incomplete multibyte or wide character: "/media/[me]/Seagate BUP/ACNH Sounds 2/Bgm_Base/�.bwav"
Aborted (core dumped)

I can't seem to figure out any way to fix this on my own. If you'd like to try and duplicate it, I've included the problematic file. Extracted from ACNH.

Bgm_Base.zip

[jackz314]

I actually tested on bgm_base before, it seems like a special case that points to other files instead of containing the data itself. But I have no idea how it's actually structured, I did extract a bunch of BWAV segments from it, but most of them are blank, and only a few of them are actual sound effects.

If you figured out its structure, feel free to let me know and I'll update the code.

[Ender97]

I've been browsing around Bgm_Base, and you seem to be spot on. Most of the blank segments I've pulled appear to be similar lengths to BWAVs found in ~/Sound/Resource/Stream, which leads me to believe they're the "real" referenced files. Here's what I've figured out so far:

When I look at the individual BWAV files, they're all rather stub-like. They terminate before the actual "meat" of the file would begin. From what I've gathered, these stub files are almost always 128 bytes of data, and most of the time the last 32-48 bytes are just a bunch of nulls.

On the other hand, a good example of one that actually has a sound begins at 004F1080 and ends at 004F5130. I could tell this was a "real" sound because of the larger length of the data. I extracted it manually, and it had to be a hundred times longer.

This seems like a bit of a dirty solution, but is there a way to make the code recognize and exclude the stub files based on the total 128 byte length and the nulls at the end? I think "real" sound files should be longer than this anyway.

Sorry if I'm messing up any terminology here! I majored in English back in college.

(By the way, Windows .exe works great after I added MinGW to Path. Nice!)

[jackz314]

Finally had some time to look at this, sorry for the long wait.

I just updated the build, now it should work on its own without the need for MinGW libraries.

About the solution, I don't think it's really necessary since after the files are generated, you can just sort the files based on their sizes and decide which ones to keep by yourself. Of course, this is possible to be implemented in code, but since this can be fixed pretty easily, and the actual solution is not really ideal, I just don't think it's worth it to implement it. I'm open to pull requests though, so feel free to open one if anyone has a better fix than this hack.