SQ3: Where is "Where am I?"?

[ZvikaZ]

I decided that simply making a temporary ASCII named copy for SoX wasn't that big of a chore, so here is test build for you to try. If you report that it is OK I'll update the Wiki with the new build.

It solved the information table problem - it shows the information for Hebrew files.
However, when I click 'Append', it fails with "Error: String cannot be of zero length. Parameter name: oldValue".
The failure is both for Hebrew and English file names.

[Collector]

I didn't look beyond the loading of the WAVs. I did change the display in the listview to show just the file name without the path. I'll have to look at the append method to see if it was getting the path to the files from the listview. An easy enough fix.

As I said, this was my first C# project. It was how I first taught myself C#. A lot of the coding is... clumsy. I have never revisited it given that the abilities of Companion have made it mostly obsolete. If there is a need for it perhaps I need to clean it up and redo it.

[Collector]

OK, give this a try.

[ZvikaZ]

OK, give this a try.

When I start it, it says: "Unhandled exception" (etc.). If I click "Continue", I get 2 dialog boxes, with "FormMain_GetFocus".
Then the GUI looks OK. Adding Hebrew files seems to work OK, with the correct information table.

However, when I click "Append" button, it writes in the status line "Sound file appeneded with בדיקה.wav" - but the files doesn't appear in the expected directory.
I found it in "C:\Users\Zvika\AppData\Local\Temp", and it's indeed a good file!

So, bottom line, 2 problems are left:
- The unhandled exception and the strange dialog boxes upon startup
- Copy back the resulting sound file from temp directory to original directory

Thanks

[Collector]

It looks like the actual AddWav.exe program does not like Unicode either, so I will have to deal with non-ASCII file names completely via the GUI. It uses SoX not just for extracting the header info of the WAV files, but also for downsampling them to prepare them for AddWav. Gumby updated a few of these DOS tools to Win32, but I don't think he did AddWav. If this GUI and the tools it uses are useful to translations I might think about redoing it to fix where Unicode breaks it if you are willing to test it for me.

Anyway, here an updated version. It will now output to the same folder as the original WAV. That particular error code does not seem to break it, so I set the error reporting to ignore that warning. Could you try a resulting embedded SOUND resource in an actual SCI game to be sure that it is producing a good SOUND resource?

[ZvikaZ]

It looks like the actual AddWav.exe program does not like Unicode either, so I will have to deal with non-ASCII file names completely via the GUI. It uses SoX not just for extracting the header info of the WAV files, but also for downsampling them to prepare them for AddWav. Gumby updated a few of these DOS tools to Win32, but I don't think he did AddWav. If this GUI and the tools it uses are useful to translations I might think about redoing it to fix where Unicode breaks it if you are willing to test it for me.

Anyway, here an updated version. It will now output to the same folder as the original WAV. That particular error code does not seem to break it, so I set the error reporting to ignore that warning. Could you try a resulting embedded SOUND resource in an actual SCI game to be sure that it is producing a good SOUND resource?

This one is better. However, when creating the sound file, it tries to create it in "C:\Program Files (x86)\SCI Sound Utilities", and fails because Windows denies access to that path.
You can see this one for yourself, it fails also with English file names.

Anyway, I'm not really sure that fixing the Hebrew file names issue is such important :-)
If you want to continue, I'm happy to test your fixes. But if it wastes your time, well, a simple warning message can do as well...

[Collector]

That is strange, it should be outputting to the same folder as the original WAV file. It is not doing that on my machine. I am running it out of VS, not an installed copy. You can try deleting the Registry key it created to see if that helps. One of the tings I am doing is converting the settings over to XML instead of the Registry.

HKEY_CURRENT_USER\SOFTWARE\SCI Sound Utilities

Also, I take it that you are using the tool from the main form, not the secondary AddWav form. I have not touched that one, yet.

Now that I have started, I have been more or less refactoring it to fix the silly newby errors and using more "best practices". Hebrew would not be the only thing that it would be good for it be Unicode. Any European language that uses diacritics might choke on it.

[Collector]

As I noted, Gumby ported some of these tools to Win32. I can't find any source for AddWav. Gumby, if you see this did you have the source to it? Did you just reverse engineer it for your ExtractWav?

[MusicallyInspired]

There's no source for AddWave. NRS didn't provide any.

[Collector]

I had forgotten that NRS wrote it. I don't think he has ever released any source from his projects. As I noted, Gumby did write ExtractWav, which does the reverse. Not sure how hard it would be to recreate AddWav to support Unicode, but probably beyond my abilities.

[gumby]

Yeah, I don't have any source for AddWave.  I've attached a zip file of the executables and C# sources that I created nearly a decade ago... hopefully it'll help.  Collector, I think you are right that I must have just created the AddWave functionality in the SCI Sound Utilities application by using/inspecting the ExtractWave functionality.

[MusicallyInspired]

According to what NRS told me way back when, it's "basically" just amending audio data onto the end of the file. But I'm sure it has to change some header information too.

[Collector]

I already have your source for ExtractWave. Feel like taking it on to recreate AddWave with Unicode support?

[Kawa]

* appending

[gumby]

I'll take a look at it this weekend.  My only hesitation is around the LZW encoding.