37 replies to this topic

[Sam.]

'Miloch', on 11 January 2010 - 02:10 AM, said:

'Sam.', on 06 January 2010 - 06:02 AM, said:

Can's NearInfinity convert them to .mp3 when it extracts them?

Yes, though NI doesn't batch convert stuff.

It can auto-convert .wavc files to .wav during a Mass Export, but not, it seems, .bmu to .mp3.

'Miloch', on 11 January 2010 - 02:10 AM, said:

One oddity I noticed with WAVC conversion is that they play about half-speed in NI, though the IESDP game says the engine plays them at double speed, which it seems to do (in other words, correctly). Just kind of odd how NI seems to play WAVCs provided with the game at the speed they should be but ones you've added at a slower speed.

Do they play at the proper speed in-game?

[Miloch]

'Sam.', on 11 January 2010 - 06:16 PM, said:

Do they play at the proper speed in-game?

They seem to, more or less. If there's a variance it certainly isn't as slow as half-speed as played in NI.

[Sam.]

Version 3.02 has been released. See the 1^st post for more details and the download link. Post any bugs/problems/issues/questions/suggestions here. New in this version is a BMU to mp3 converter, the MP3Gain utility, a StatusBar, and a fix for an error in the R-click WAV to WAVC conversion.

[Miloch]

'Sam.', on 11 January 2010 - 06:16 PM, said:

'Miloch', on 11 January 2010 - 02:10 AM, said:

One oddity I noticed with WAVC conversion is that they play about half-speed in NI, though the IESDP game says the engine plays them at double speed, which it seems to do (in other words, correctly). Just kind of odd how NI seems to play WAVCs provided with the game at the speed they should be but ones you've added at a slower speed.

Do they play at the proper speed in-game?

I figured out what the deal was with these. If you convert WAVs that are 44khz, they'll play at half-speed in NI/acm2wav, though presumably the engine figures out the real speed. 22khz WAVs sound fine either way though, and since that seems to be the standard, you may as well convert all your files at that rate since it seems to be the game default (also as PCM signed 16 bit mono). In fact, modders should really stop doing OGG files and make them WAVCs instead, since they're both lossy and the OGG compression rate isn't all that much better. Not to mention it's a lot easier to do COPY ~mymod/wavc~ ~override~ instead using a bunch of batch files for oggdec.

The status bar is nice - I was going to ask for that. Also maybe a "conversion complete" notification, though I suppose once it says "Idle" again it's much the same thing. Another thing that would be good is if it "remembered" the last path(s) you used for converting, maybe via an autogenerated .ini file or something.

[Sam.]

'Miloch', on 16 January 2010 - 01:53 AM, said:

'Sam.', on 11 January 2010 - 06:16 PM, said:

'Miloch', on 11 January 2010 - 02:10 AM, said:

One oddity I noticed with WAVC conversion is that they play about half-speed in NI, though the IESDP game says the engine plays them at double speed, which it seems to do (in other words, correctly). Just kind of odd how NI seems to play WAVCs provided with the game at the speed they should be but ones you've added at a slower speed.

Do they play at the proper speed in-game?

I figured out what the deal was with these. If you convert WAVs that are 44khz, they'll play at half-speed in NI/acm2wav, though presumably the engine figures out the real speed. 22khz WAVs sound fine either way though, and since that seems to be the standard, you may as well convert all your files at that rate since it seems to be the game default (also as PCM signed 16 bit mono). In fact, modders should really stop doing OGG files and make them WAVCs instead, since they're both lossy and the OGG compression rate isn't all that much better. Not to mention it's a lot easier to do COPY ~mymod/wavc~ ~override~ instead using a bunch of batch files for oggdec.

The only 44100Hz ACM and WAVC files that I found in my game were added by CA. While every one of the WAVC files were 16-bit signed PCM, many of them (over 1000) were stereo, which is perfectly fine.

'Miloch', on 16 January 2010 - 01:53 AM, said:

The status bar is nice - I was going to ask for that. Also maybe a "conversion complete" notification, though I suppose once it says "Idle" again it's much the same thing. Another thing that would be good is if it "remembered" the last path(s) you used for converting, maybe via an autogenerated .ini file or something.

I added the conversion complete notifications today along with a couple other fixes. The "remembered paths" has been on my to-do list for quite some time. I'll probably get to it and hopefully one other thing sometime this week before uploading the next version. Thanks for the feedback. It is really appreciated.

[Sam.]

Version 3.03 has been released. See the 1^st post for more details and the download link. Post any bugs/problems/issues/questions/suggestions here. New in this version is:

• Added conversion complete notifications.
• Started adding ?remembered paths?.
• Updated OggEnc2 to v2.87
• Updates OggDec to v1.97
• MVE2AVI radio/checkbox selection structure revised.
• Made the R-Click and File Extension Association conversions more silent.
• Made some changes trying to prevent erroneous ?File not found? errors.
• Made MANY other updates that I can?t remember the specifics of (I lost my list).

[Sam.]

PS gui has been updated to version 3.04. See the 1^st post for more details and the download link. Post any bugs/problems/issues/questions/suggestions here. The changes are as follows:

• Made more changes trying to prevent erroneous "File not found" errors.
• Fixed a minor bug where WinActive would activate the wrong window if a folder called "PS gui" was also open.
• WAV2WAVC now outputs to a folder called "WAVC" inside the user-defined output directory when the output dir is the same as the input dir. This prevents the original WAV files from being overwritten by their WAVC counterparts.
• WAVC2WAV now outputs to a folder called "WAV" inside the user-defined output directory when the output dir is the same as the input dir. This prevents the original WAVC files from being overwritten by their WAV counterparts.
• Added support for RAD Video Tools. It must be installed separately by the user. It is free and can be found HERE.
• Added automatic RAD conversion on 8-bit input to WAV2WAVC conversion.
• Added menu to select which extension association conversions and icons to install.
• Fixed an error where the ACM2WAV outputs went to PS gui's home directory instead of the designated output.
• Ensured file names stay long instead of converting to 8.3 short names on drag&drop conversions as they sometimes did. (Although this may have only been happening while running the script in its uncompiled form.)

[Eric P.]

It may be worth noting that stereo files are twice as large, in file size, as mono files. 44.1 sampling rate will also yield larger files than 22 sampling rate.

Edited by Eric P., 17 March 2012 - 10:30 AM.

[Jarl2]

Great tool! Thanks a lot

[Sam.]

'Eric P.', on 17 Mar 2012 - 18:30, said:

It may be worth noting that stereo files are twice as large, in file size, as mono files. 44.1 sampling rate will also yield larger files than 22 sampling rate.

This is typical of pretty much all audio file formats, not just ACM/WAVC files.

'Jarl2', on 03 Apr 2012 - 17:44, said:

Great tool! Thanks a lot

Glad you found it useful . If you have any suggestions or find any bugs, please let me know here.

[TrancingBear]

I'm trying to convert a series of JPG files into an AVI, and then convert the AVI into an MVE for use in IWD2.  I used VirtualDub to create the AVI, which I can successfully play using Windows Media Player.  But when I then run PS GUI to convert it to MVE, I get this in pass 1

 

Exception EAccessViolation in module avi2mve.exe at 00002615.

Access violation at address 00402615 in module 'avi2mve.exe'. Write of address 010733D4.

 

I can only assume that VirtualDub created an AVI format that PS GUI doesn't like.  Any idea what settings I should use in VirtualDub that will produce a supported AVI format?  Thanks!

 

- TB

 

UPDATE: never mind.  Turns out BINKing the AVI with the RAD Video Tools did the trick.

Edited by TrancingBear, 28 April 2019 - 09:17 AM.

[Sam.]

TrancingBear, on 28 Apr 2019 - 17:09, said:

I'm trying to convert a series of JPG files into an AVI, and then convert the AVI into an MVE for use in IWD2.  I used VirtualDub to create the AVI, which I can successfully play using Windows Media Player.  But when I then run PS GUI to convert it to MVE, I get this in pass 1

 

Exception EAccessViolation in module avi2mve.exe at 00002615.

Access violation at address 00402615 in module 'avi2mve.exe'. Write of address 010733D4.

 

I can only assume that VirtualDub created an AVI format that PS GUI doesn't like.  Any idea what settings I should use in VirtualDub that will produce a supported AVI format?  Thanks!

 

- TB

 

UPDATE: never mind.  Turns out BINKing the AVI with the RAD Video Tools did the trick.

I am unfamiliar with the internals of avi2mve; PS GUI is just a wrapper for the command-line program.  FWIW, I think the safest bet is to use a fully uncompressed AVI.

[Sir-Kill]

link in first post is missing -ps-gui/ at the end. I was looking for plt to bam and found this. You are a madman.

[Sam.]

Sir-Kill, on 14 Mar 2021 - 02:39, said:

link in first post is missing -ps-gui/ at the end. I was looking for plt to bam and found this. You are a madman.

Links updated.  Note that I didn't write the PLT<>BMP converters, I just provided a GUI front-end for them.  Because of differences in the PLT and BAM file formats, the conversion is not 1:1.  Also, most PLT files in games including 1pp (including the EEs) are blank placeholders.

[Sir-Kill]

Yeah, I noticed that but I could not figure out as to why. I moved all plt's out of my override, now NI can view/extract them. There is potential x 16 now.

[Sam.]

Sir-Kill, on 15 Mar 2021 - 00:25, said:

Yeah, I noticed that but I could not figure out as to why. I moved all plt's out of my override, now NI can view/extract them. There is potential x 16 now.

If there is a PLT and a BAM for the same animation in the game, the PLT will take precedence.  Erephine/1PP tended to prefer BAMs, so the PLTs were overwritten with blank files so that the game would be forced to use the BAMs instead.

[Sir-Kill]

Well I found out why she did that. Erephine or someone added more colors than the original game; plt's crash when those higher colors are used on them.

[Sir-Kill]

Hahaha, ok It is late and I have been at this for hours. I placed the 'higher color' # in the location spot.
Time for sleep.
Edit: So no crash
move along, nothing to see here

Edited by Sir-Kill, 14 March 2021 - 11:20 PM.