Exported audio format the same for WAV and -stdin?

[CoRoNe]

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?

[Gale Andrews]

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:

Code: Select all

"<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

[CoRoNe]

I haven't asked on the Hydrogenaudio forums, simply because this only happens with Audacity. I've been using WavPack ("<path to exe>" -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 "<path to exe>" -hhx - "%f" and "<path to exe>" -e -pMax - "%f", but as a result I get:

Code: Select all

WavPack:
- is an unsupported .WAV format!

TAK:
< STDIN                             .......... Audio format not supported

Just like Lame, FLAC with "<path to exe>" -8 - -o "%f" and OPUS with "<path to exe>" --music --bitrate 64 - "%f" seem to work too, BUT OPUS may have the key to this issue:

Code: Select all

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.

[CoRoNe]

Is it possible for any Audacity developer to fix this issue?

[Gale Andrews]

Is it possible for any Audacity developer to fix this issue?

What issue?

Code: Select all

"C:Program Files (x86)wavpack-4.60.1wavpack.exe"  -hhx - "%f" 

gives

Code: Select all

 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 ( http://en.wikipedia.org/wiki/Opus_%28codec%29) 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

[CoRoNe]

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!

Code: Select all

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%)

Code: Select all

D:Takc.exe -e -pMax - "%f"

< STDIN                             ..........  48.11%   10* 

Compression:     48.11 %
Duration:        13.36 sec
Speed:           10.09 * real time

Code: Select all

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.