Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: AIFF support added to WavPack command-line progs (Read 2279 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

AIFF support added to WavPack command-line progs

By popular demand I have added Apple’s AIFF to the list of WavPack’s supported import/export formats. Most uncompressed versions of AIFF are supported, including 32-bit float data and the AIFF-C/sowt little-endian version that Apple switched to after adopting Intel CPUs. 64-bit float is not supported.

As with the other supported formats, existing WavPack files can also now be exported to AIFF files. The new options are --aif, which will generate old-style AIFF files (except for float32, which requires AIFF-C) and --aif-le which will generate little-endian AIFF-C/sowt files (except for float32 files which cannot be little-endian). Of course, the default behavior of wvunpack remains restoring the original file and extension verbatim.

Assuming all goes well this will become 5.6.0 in the near future.

Any testing, comments or criticism is gladly accepted. Well, the latter maybe grudgingly.  :D

Re: AIFF support added to WavPack command-line progs

Reply #1 –
So - nice surprise but I guess WavPack 5 was designed for this - WavPack 5 is forward compatible and can unpack aiff-file.wv. At least every one I tested. (Of course I couldn't help myself trying to unpack them with 4.80 as well ...)
From information you have provided earlier, AIFF can have non-integer sampling rate, and you would have to hide that away from the old decoder (with the BIG reservation that if I remember correctly).
Spawns the questions:
* All wvunpack 5.x will encode & completely restore these files too?
* ... but, players based on versions earlier than 5.6 and the corresponding libraries will be slightly off in speed - and so conversion using such players (like fb2k) will not be lossless?
* ... if so: what library versions - if any - will provide warning that "this integer sampling rate is only there to enable listening and is not the correct one"?
* You mentioned scientific data, which could have like, one sample per hour. Not intended to be played as audio ... will it scream bloody murder if I attempt to? ;-)

Quote from: bryant on
--aif, which will generate old-style AIFF files (except for float32, which requires AIFF-C) and --aif-le which will generate little-endian AIFF-C/sowt files (except for float32 files which cannot be little-endian).

Meaning, from the at https://en.wikipedia.org/wiki/Audio_Interchange_File_Format#Common_compression_types ,
wvunpack will be able to force integer PCM streams output to (1) ordinary AIFF, (2) AIFF-C "sowt", but not AIFF-C "NONE"? Not sure if anyone will miss it. ("to force" meaning, if it wasn't that already; I presume that an AIFF-C "NONE" will be restored by default.)

(And huh, fl32 vs FL32 ... is the latter another "Audition" type float?)

Re: AIFF support added to WavPack command-line progs

Reply #2 –
Thanks for trying it out, Porcus!

Yes, these new files should be compatible with older 5.X decoders because the headers, information on how to format the audio, and the filename extension are all stored in the WavPack file. Even older (< 5.0) decoders should be fine with them too audio-wise and should generate valid WAV files. And other programs (e.g., FFmpeg) shouldn’t even be able to tell the difference because they ignore the new metadata. This is all part of WavPack’s schizophrenia; it doesn’t know whether it’s a file archiver or an audio codec!

As for the non-integer sample rates of CAFF and AIFF files, thanks for reminding me! With CAFF I decided to just error out on non-integer sample rate files and so far nobody’s complained (WavPack can’t store those rates). Currently with AIFF I just truncate the rate, but that’s probably not ideal. I’ll think about your idea of rounding to the nearest integer (except zero) and display a warning that the fractional part will be lost. It will not survive going through WavPack, but of course the original header is restored (unless you force something else).

AIFF-C “none” is handled on input and restored verbatim, but cannot be forced on output because I can’t really see a purpose. It provides no new information or formatting and must be less compatible than standard AIFF.

And finally, yeah, I couldn’t find anywhere that a difference between fl32 and FL32 is described. Your guess that it might be a different normalization (like Audition) is not unreasonable, but I could not find anything about that in documentation for SoundHack or Csound. Another guess is that one of them created the new format unofficially and then when Apple created the same thing they made it lower-case instead. I created some and played them on FFplay and Foobar2000 and loaded them into Audacity (libsndfile) and they all treated them the same. So I’m in good company!