Will you mind if i post something to "image conversion" and "SFX conversion"?
OK you can't i posted it already
PNG is for sure the right choice and well there is not many image on my windoze which isn't in this format (check this and you will know why https://photos.app.goo.gl/ReS6SnCsd4Vw5Qw991
) and no i HATE (a thick fat HATE) DDS textures they are more lossy as jpeg!
(an 8 bit image will be reduced by DDS to about 128 colors, that's the "compression" they talk about a complete loss of half of the data just to make it possible to have a useless high graded alpha channel in the same bitmap. I experienced for alpha blending that 32 colors are more as enough, sure PNG can't store or calculate reduced mipmap images but that a small advantage compared to the loss of data and the alpha is either 1 or 8 bit, neither that i have a performance drop by using PNG instead of the by my mates chosen DDS on my miserable notebook resumeé: DDS has no advantages for me resp. it has no advantage for OpenGL driven 3D).
NEW DOESN'T EQUAL ALWAYS TO BETTER (you know it)
To convert IFF to PNG and back i use XnView, it never failed (for the ~300 images which i converted), my common image editor/paint program is as you can guess GIMP, it had an IFF exporter for 2.08 but it fails in 2.10 and apart from that it never was as good as XnView, GIMP exported them always as 8bit images but since i run even a OS1.3 recently most images have 2 bitplanes to be used with SimGen (or WBPic). XnView keeps the 2 bitplanes but has no idea about 4, however 4 and 8 color (next recognized for XnView is 32 colors) will have a stripped palette and PNG can very well respect this respectively it is pretty the same here (unlike GIF which is always 8bit). In other terms an IFF using only 2 or 4 colors will also have only set these two or four for the exported PNG and vice versa, this helps to keep the palette DPaint (or similar) won't have to recalculate the palette for fewer colors.
Portable Network Graphics how aged is this format?
Does that play any role?
They won't create a better tomorrow and not in hundred years, it stores a bitmap and it stores it lossless compressed.
And to be honest i neither can see that IFF/ILBM would become obsolete, i mean they store bitmaps that's all and any new format can't do it better as to use a huffman compression. They only reason to have new formats is to make the old obsolete, there is no real gain possible!
(except you cheat like for DDS and claim like nowadays every nine to fiver does how fantastic and unique and million times...
...worse it is).
Well just as long until someone examines the result with a looking glass.
To the SFX wave and all that surf,
In general one could say about wave formats the same as about images "it's a bitmap and to store this bitmap not many possibilities you have except to store it byte by byte".
Thus in advance any "new" format can't be better as what we have since it can't be made different as to store them byte by byte, except compression but also here it is the same huffman code which is used from A to Z.
Thus i don't htink that your 8SVX will be ever obsolete because they do what they was meant for.
And well what have we if we peep into them?
The same data for all, differences are mostly the use of signed samples for the Miggy while doze prefer unsigned and 16 audio has to be either "little endian" or big "endian" (or as i would say read bytes backwards (little endian) and read bytes forward (big endian)).
8SVX would be a pretty good format IFF EA's interchange file format, likewise SB for VOC they thought about a lot of use for games even if the features was rarely used. Intentionally, as i have read, 8SVX is to store instrument samples, but apart from this the format (header structing of IFF files) offers things (or would) like to set loop markers and loop times, thus a SFX could have a start and loop in itself in a smaller section, it would allow to store the volume, channel use, a lot of things and it is extendable with everything compliant to IFF. What it can't what in example VOC could is to suppress silent passages to zero and to store a silent passage as instruction rather as data, but well apart from the original SB16 software none can make use of the many features of VOC. Similar for 8SVX i guess its capabilities has never been fully used thus obsolete if something isn't explored right yet?
Stereo, VOC as example wasn't and well you know 8SVX neither, but since it is a format to store instrument samples there is an addressing for a so called "high octave" of the sample this had been abused for the a bit strange 8SVX stereo.
The idea is right - the execution bad.
To convert from and to 8SVX i use no other as i use else - Audacity.
Audacity (respectively FFMPEG) will resolve the special stereo of 8SVX proper (with which the native machine has problems as well, later more). Files can fail to be resolved proper as stereo but one can claim what fails to be resolved here fails even on the miggy (certain sound players are far more picky as audacity about "stereo"). Audacity can't export to stereo samples, one could claim "because stereo doesn't exists for 8SVX" which is neither false nor true.
In fact you will find NO program who can do this and have to use a tool from the miggy i.e. "join2stereo".
It's no magic "join2stereo" simply takes the two mono samples and glues them together while writing to the "high octave" address the address where the let's say "other", because it could be theoretically be any of the four, channel starts, you can do that as well with a hex editor, it's no magic...
...and here is already the source for the errors.
That is a) the stiff limit that stereo samples need to be even in length and there is no exclusion to this
even more worse
the header size as to be uneven in length else the whole file will be uneven in length and then a possible Stereo won't be interpreted right and one channel is played back after the other like they are stored, Audacity and any player on your miggy will fail to play them proper back, but as i look at this problem it could be solved right it just was solved sloppy.
A header is just a header and header A is to me like header B, in general samplerate, bitdepth, little or big endian (for some formats) stereo flag, length in bytes.
What i guess the dudes made wrong;
In the 8SVX header you declare the header size by "total filesize from here", as usual the entry code to declare what it is is disregarded it won't be count to filesize, no matter which format in this all behave the same, after this follows the string, that's why i need to declare a size "8SVX", then to shortcut it samplerate and all that tidbits, After you would be quite free what you declare in the header, it's IFF! The first keyword entry after "all the tidbits" has a leading "FF" as length and i assume - i highly assume this sloppy use is part of the reason for the failure, it declares simply a "unspecified length" any of the following to read out data has a proper length before the data follows. Finally after all that (it could be nothing since AUTHOR,NAME,COPYRIGHT etc. all this is not of need just to play back) the keyword DATA and the length from here start the audio stream.
The main problem is now that if the header has a total length which has an even count the total file size will have an odd number and this provokes the error.
Personally i would stick the files together and instead to write each time a header which uses the filename as NAME to use no NAME since the name is what changes from even to odd, or to use a fixed space for the naming i mean 31 bytes would be fairly enough for a name. Same for AUTHOR maybe to keep the ones name who put his dirty fingers on the data, 31 glyphs are fairly enough, besides the exporter of Audacity uses exactly such a template header with always the same size, no NAME in it therefore as AUTHOR a fixed string of the developers name, IFF is flexible enough to accept if there is no filename stored in the header.
However the stereo can still fail even if you respect the odd length of the header, it seems ideal is likewise it would be 16bit to up or downsize by always 4 bytes (i assume since a name with three chars works, five not, seven yes but nine not, at first glance you get the impression it has no rule but the rules is "4 bytes" e.g. 3,7,11 and so on, if i look now at what i wrote it's obvious since we have for stereo two sequential joined tracks thus the resulting "gap" is 4 bytes (two times two bytes) and would be for 16 bit data 8bytes.
This is badly done, "join2stereo" (btw i haven't found any other good to use from cli) will argue if the input is odd but then it totally disregards the above rule and any exported stereo 8SVX with a filename length of 4,5,6,8,9 etc. bytes will fail to be played back proper as stereo, one player so far can correct this common error "SOUND" (gramma software, RL Stockton) he implemented a stereo switch which is (undocumented by him what it is for) exactly to correct this error, while it will then disregard the header length and play it together with the data which results in a short noise at start.
"Meiner bescheidenen Meinung nach"
In my humble opinion it shouldn't be such a big thing to write something which works always and if i have to script it (goddammit!), it's neither magic to poke a few variables in the header.
Erm alright i leak a little of a few proggies such as a lightweight database handler it just has to read/write data and respect undefined field separators, a header is like a short database - any, no super fancy "i can do all" just something which comes close to "nset" which i used countless times in my doze (in fact i hacked nset, it had as fixed field seperator with highest priority "space" (0x20) but dammit "space" can be in any string and since i don't like to manipulate a stupid brokers table it's useless, i changed it to "semicolon" as fixed field seperator with highest priority any other you can define but one is given (there is a reason for this but i would have to lookup what i experienced then).
A header is easy to read out and to write back to it, and it should be no problem to make a "four byte rule", in other terms to fill a string if it doesn't matches the above stated rule of 3,7,11...
If that all fails i write a new header type
you see audio streams aren't as complicated as images to be honest and in fact i wrote one - a scripted header and it works fantastic (in DOS).
A last word to this (audio) mess,
You can use a web service to convert from and to 8SVX, personally i wonder what they perform with the feed files because they show exactly the same error as when i convert it using "join2stereo", rooted in the same the length of the name string.
Yeah this makes it obsolete, indeed or as one replied my in the audacity forum "which developer should have interest to write an export plugin for this OBSCURE format"
cough (three times)
It is not as much or less obscure as any else PCM wave format, it's pretty the same as any.
In what do they differ?
In general only in the header the data is always a raw PCM sample.
If 8SVX is obsolete then the whole PCM wave construct is obsolete and i guess that is wrong.