I’ve been trying to export audio (44100,32f,2 > 44100,16,2), using the external program command-line, to WavPack (wavpack.exe) and TAK (takc.exe), but I’m constantly being told unsupported .WAV format! (WavPack) and Audio format not supported (TAK). Exporting to FLAC (internal ffmpeg) and MP3 (external lame.exe) does work however and produces the exact amount of samples. With WavPack I discovered appending “–raw-pcm” (quote wavpack.exe --help: input data is raw pcm (44100 Hz, 16-bit, 2-ch)) does work, but the end result has a surplus of 11 samples somehow. TAK doesn’t have an option to force raw pcm, and so one can’t export to TAK at the moment.
Although lame.exe accepts Audacity’s stdout, I’m beginning to wonder if its stdout really is something most audio-encoder-binaries can handle. Or am I doing something wrong?
Have you asked on the TAK, WAVPACK or Hydrogenaudio forums? Does TAK saving work for example with Foobar 2000 at the command-line?
It is certainly incorrect that the WavPack encoder requires headerless PCM input as I just converted a headered 44100 Hz, 16-bit, one channel PCM WAV using “WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.60.1” at the Windows command prompt. I also exported to WavPack from 32-bit float Audacity content, pointing Audacity to that same encoder:
"<path to wavpack.exe>" - %f
The number of samples exported was the same as that in the content.
External export is just provided as a convenience, really. You shouldn’t assume exporting as (external program) supports anything except LAME or FFmpeg. I haven’t tried the TAK encoder on its own or in Audacity as I have never heard of anyone using that format until today, but if you can demonstrate that the TAK encoder actually works in other programs, giving the exact command that works in other programs but not in Audacity, we could take a look.
Gale
I haven’t asked on the Hydrogenaudio forums, simply because this only happens with Audacity. I’ve been using WavPack (“” -hhxi - %d) and TAK (-e -pMax -ihs - %d)for a long time now in Foobar (and other software) without any problems. In Foobar you have to setup the external encoder to ignore the wave header length as you can see, or it won’t work. In Audacity I believe this isn’t necessary, so the command-lines would be respectively “” -hhx - “%f” and “” -e -pMax - “%f”, but as a result I get:
WavPack:
- is an unsupported .WAV format!
TAK:
< STDIN .......... Audio format not supported
Just like Lame, FLAC with “” -8 - -o “%f” and OPUS with “” --music --bitrate 64 - “%f” seem to work too, BUT OPUS may have the key to this issue:
Warning: WAV 'block alignment' value is incorrect, ignoring.
The software that created this file is incorrect.
Encoding using libopus 0.9.11-142-g32024cb-exp_analysis (audio)
-----------------------------------------------------
Input: 44.1kHz 2 channels
Output: 2 channels (2 coupled)
20ms packets, 64kbit/sec VBR
Preskip: 356
[|] 00:00:00.02 2e+004x realtime, 61.02kbit/s
[|] 00:00:09.43 9.44x realtime, 63.98kbit/s
[/] 00:00:27.00 13.5x realtime, 63.78kbit/s
[-] 00:00:44.14 14.7x realtime, 63.16kbit/s
[] 00:01:01.75 15.4x realtime, 62.74kbit/s
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 10.66 seconds
Runtime: 4 seconds
(17.66x realtime)
Wrote: 553237 bytes, 3533 packets, 73 pages
Bitrate: 61.9874kbit/s (without overhead)
Rate range: 1.2kbit/s to 130.8kbit/s
(3 to 327 bytes per packet)
Overhead: 1.04% (container+metadata)
I hope this clears things up a bit.
Is it possible for any Audacity developer to fix this issue?
What issue?
"C:Program Files (x86)wavpack-4.60.1wavpack.exe" -hhx - "%f"
gives
WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.60.1
Copyright (c) 1998 - 2009 Conifer Software. All Rights Reserved.
creating S:hhx.wv, 0% done... 6% done... 8% done... 14% done... 17% done... 22% done... 25% done... 30% done... 33% done... 39% done... 41% done... 47% done... 50% done... 55% done... 58% done... 63% done... 66% done... 72% done... 74% done... 80% done... 83% done... 88% done... 91% done... 96% done...
created S:hhx.wv in 1.35 secs (lossless, 73.68%)
I note if I remove the “-hhx” that the output file is larger, so the extra compression seems to have an effect.
If “opus” is something to do with OggOpus ( Opus (audio format) - Wikipedia) the format hasn’t even been released yet.
We have bug priorities of 1 to 5, even if there was some issue this might just scrape a 5, and an unreleased / unheard of format a 50.
Gale
I don’t think you understand. It wasn’t about Opus specifically, but rather its message telling me Audacity’s -stdout is faulty and hence the reason why WavPack and TAK couldn’t handle it. I’m talking in paste tense, because I noticed I was still using version 2.0 and although I can’t find anything related in the 2.0.1 release-notes, 2.0.1 doesn’t have this issue anymore. wavpack.exe, Takc.exe and opusenc.exe all work fine now!
D:wavpack.exe -hhx - "%f"
WAVPACK Hybrid Lossless Audio Compressor Win32 Version 4.60.1
Copyright (c) 1998 - 2009 Conifer Software. All Rights Reserved.
creating test.wv, 0% done... 1% done... 2% done... 4% done... 6% done... 7% done... 8% done... 9% done... 10% done... 11% done... 13% done... 15% done... 16% done... 17% done... 18% done... 19% done... 20% done... 22% done... 24% done... 25% done... 26% done... 27% done... 28% done... 29% done... 31% done... 33% done... 34% done... 35% done... 36% done... 37% done... 38% done... 39% done... 40% done... 41% done... 43% done... 45% done... 46% done... 47% done... 48% done... 49% done... 50% done... 52% done... 54% done... 55% done... 56% done... 57% done... 58% done... 59% done... 61% done... 63% done... 64% done... 65% done... 66% done... 67% done... 68% done... 69% done... 70% done... 72% done... 74% done... 75% done... 76% done... 77% done... 78% done... 79% done... 80% done... 81% done... 82% done... 84% done... 86% done... 87% done... 88% done... 89% done... 90% done... 91% done... 93% done... 95% done... 96% done... 97% done... 98% done... 99% done...
created test.wv in 12.61 secs (lossless, 47.44%)
D:Takc.exe -e -pMax - "%f"
< STDIN .......... 48.11% 10*
Compression: 48.11 %
Duration: 13.36 sec
Speed: 10.09 * real time
D:opusenc.exe --music --bitrate 64 - "%f"
Encoding using libopus v1.0.1-rc (audio)
-----------------------------------------------------
Input: 44.1kHz 2 channels
Output: 2 channels (2 coupled)
20ms packets, 64kbit/sec VBR
Preskip: 356
[|] 00:00:00.02 2e+004x realtime, 61.02kbit/s
[|] 00:00:08.00 8x realtime, 64.01kbit/s
[/] 00:00:19.73 9.87x realtime, 63.89kbit/s
[-] 00:00:31.28 10.4x realtime, 63.62kbit/s
[] 00:00:44.74 11.2x realtime, 63.26kbit/s
[|] 00:00:56.26 11.3x realtime, 63.24kbit/s
[/] 00:01:09.73 11.6x realtime, 63.13kbit/s
[-] 00:01:23.68 12x realtime, 63.06kbit/s
[] 00:01:37.78 12.2x realtime, 62.87kbit/s
[|] 00:01:53.44 12.6x realtime, 62.91kbit/s
[/] 00:02:09.52 13x realtime, 62.88kbit/s
Encoding complete
-----------------------------------------------------
Encoded: 2 minutes and 13.86 seconds
Runtime: 10 seconds
(13.39x realtime)
Wrote: 1060261 bytes, 6693 packets, 136 pages
Bitrate: 62.7313kbit/s (without overhead)
Rate range: 1.2kbit/s to 110.8kbit/s
(3 to 277 bytes per packet)
Overhead: 1% (container+metadata)
WavPack will encode in “normal mode” (default) if you remove -hhx (very high compression (-hh) + extra encode processing (-x1)), but this had nothing to do with the issue.
And you’re right, Opus 1.0 hasn’t been released yet, but we’re very close. Discussion thread, Opus Encoder (win32), Opus 1.0.1 rc, Opus-tools 0.1.4.
Thanks for your time.