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: Opus 1.1 (Read 46330 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Opus 1.1

Reply #25 –
Quote from: lithopsian on
There have been well over a hundred commits since v1.1.  Many of them are documentation, typos, cross-platform build nits, etc, but there are some small improvements to audio of efficiency.  There are even a few outright bug fixes, although not anything you're likely to have noticed.

http://git.xiph.org/?p=opus.git;a=shortlog

And RareWare's version is also half the speed encoding.
 

Opus 1.1

Reply #28 –
HI
I notice that opus tools was updated. Please try

- based on latest libopus GIT snapshot
- based on Opus tools 0.1.9
- Intel optimized build
- FLAC decoding support
- should work on all machines

Opus 1.1

Reply #29 –
Anakunda thanks, can you make a build with the DLLs inside the .exe?

Opus 1.1

Reply #30 –
I`m afraid not because those are proprietary runtimes to compiler. just copy all DLLs to Windows system dir and you won't see them.

Opus 1.1

Reply #31 –
Quote from: Anakunda on
I`m afraid not because those are proprietary runtimes to compiler. just copy all DLLs to Windows system dir and you won't see them.

I use almost everything portable and share it too, it won't work like that for me (it will work but I don't want it like that) but I will keep them in the opusenc.exe folder until the next official release. Thanks again for compiling this!

Opus 1.1

Reply #33 –
Quote from: darkbyte on
Quote from: Anakunda on
HI
I notice that opus tools was updated. Please try


Only works with Intel CPUs. I have a AMD A10-5800K APU and it refuses to execute on it.

Thart's bad, I don't know what restrictions Intel puts on another platforms so this might happen. Please wait for official release from Opus guys, that should be 100% compatible.

Opus 1.1

Reply #35 –
As far as I can see there are some bugfixes, speed and fixed-point (i.e. ARM) improvements.
It's all the same for x86. Plus it's experimental, not stable.

I would stay with stable 1.1.0 http://www.opus-codec.org/downloads/

Opus 1.1

Reply #36 –
The 1.1-git source should be compatible with any platform, despite not being an official release at this point.  As for the rarewares build, I have no idea.

Opus 1.1

Reply #37 –
opusenc.exe accepts 32bit float directly:
Code: [Select]
opusenc.exe (--bitrate 64) input.wav output.opus

opusenc.exe accepts 32bit float through pipe from avs2pipemod.exe (AviSynth audio output is 32bit float of course):
Code: [Select]
avs2pipemod.exe -wav input.avs | opusenc.exe (--bitrate 64) - output.opus

But opusenc.exe doesn't accept 32bit float through pipe from ffmpeg.exe:
Code: [Select]
ffmpeg.exe -i input.avs -f f32le - | opusenc.exe (--bitrate 64) - output.opus

It somehow doesn't accept ffmpeg's wav headers, so you're forced to pipe AviSynth's audio as 24bit int because opusenc.exe doesn't allow --raw-bits 32:
Code: [Select]
ffmpeg.exe -i input.avs -f s24le - | opusenc.exe (--bitrate 64) --raw --raw-bits 24 --raw-rate 44100 - output.opus

Who's fault is this? ffmpeg's or opusenc's?

Opus 1.1

Reply #38 –
Quote from: CoRoNe on
It somehow doesn't accept ffmpeg's wav headers

ffmpeg doesn't output WAV headers with your settings.

Try:
Code: [Select]
ffmpeg.exe -i input.avs -acodec pcm_f32le -f wav - | opusenc.exe --ignorelength --bitrate 64 - output.opus

Maybe --ignorelength is not necessary in this case but it's safer to use it.

Opus 1.1

Reply #39 –
Code: [Select]
Guessed Channel Layout for  Input Stream #0.0 : stereo
Input #0, avisynth, from 'input.avs':
  Duration: 00:00:25.50, start: 0.000000, bitrate: 0 kb/s
    Stream #0:0: Audio: pcm_f32le, 44100 Hz, 2 channels, flt, 2822 kb/s
[wav @ 02f45fa0] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead.
Output #0, wav, to 'pipe:':
Skipping chunk of type "LIST", length 26
  Metadata:
    ISFT            : Lavf55.44.100
    Stream #0:0: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 44100 Hz, stereo, flt, 2822 kb/s
    Metadata:
      encoder         : Lavc55.68.100 pcm_f32le
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_f32le (native) -> pcm_f32le (native))
Press [q] to stop, [?] for help
Skipping chunk of type "∞┌b=", length 1034209178
Skipping chunk of type "♥▓b╜", length 1029013732
Skipping chunk of type "I╠<", length -1121968764
Skipping chunk of type "α¡E<", length 1036707121
Skipping chunk of type "¶£ç=", length -1111584288
Skipping chunk of type "nL│:", length 1029892182
Skipping chunk of type "¢²≥╜", length -1118624458
Skipping chunk of type "R²h╜", length 1043404238
Skipping chunk of type "+q"=", length -1156393065
size=    8786kB time=00:00:25.50 bitrate=2822.4kbits/s
video:0kB audio:8786kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.001134%
Error parsing input file: -
Same as always.

Opus 1.1

Reply #40 –
Well, this approach with "-acodec pcm_f32le -f wav" works with lame, wavpack and qaac and doesn't work with oggenc2 and opusenc. Interesting...

Opus 1.1

Reply #42 –
Everything is OK if I first write WAV file

ffmpeg.exe -i input.wav -acodec pcm_f32le -f wav - > temp.wav

and then use it:

opusenc.exe --ignorelength --bitrate 64 - output.opus < temp.wav

So maybe there's a problem with buffering (or something like this) in opusenc.

Opus 1.1

Reply #43 –
Quote
Code: [Select]
ffmpeg -i test.avs -vn -acodec copy -f wav - | qaac --silent -D - -o - | opusenc --ignorelength - output.opus
qaac normalizes the headers (and maybe some other stuff). Testing only with ffmpeg and qaac, the wav qaac writes to the pipe is the same format that was piped out of ffmpeg - in this case, pcm_f32le. So I'd assume that qaac isn't doing any implicit format conversions in there.

I don't have Apple software installed, so I can't use qaac, but despite some warning messages, I believe the following cumbersome method works too  :
Code: [Select]
ffmpeg.exe -i input.avs -c:a pcm_f32le -f wav - | wavpack.exe -r - - |
wvunpack.exe - - | opusenc.exe --ignorelength (--bitrate 64) - output.opus

wavpack.exe -r --> "generate a new RIFF wav header (removes any extra chunk info from existing header)". So there's something going wrong with the header while piping/buffering.

Opus 1.1

Reply #46 –
You still need to download QuickTimeInstaller.exe for qaac's makeportable.cmd to work, but uh...thanks, I didn't know that. Now I've got qaac working.

I can confirm the following 2 methods work and produce the same output:
Code: [Select]
ffmpeg.exe -hide_banner -i input.avs -c:a copy -f wav - | wavpack.exe -r - - | wvunpack.exe - - | opusenc.exe --bitrate 64 - output.opus

ffmpeg.exe -hide_banner -i input.avs -c:a copy -f wav - | qaac.exe --silent -D - -o - | opusenc.exe --bitrate 64 - output.opus

--ignorelength not needed. Strange though this works with qaac, because with qaac.exe -D you'd expect this to only work for decoding aac-streams.
As these are workarounds I hope someone can have a look at ffmpeg.exe's and/or opusenc.exe's inner workings.

Opus 1.1

Reply #47 –
Quote from: CoRoNe on
Then I'm interested to see what NullC and/or jmvalin has to say about it.


My only thought is that it's often impossible to output a correct wave file through a pipe because of the length field at the beginning. You only know the size once you've output the entire file. So different programs put in a different (fake) value for the length in those cases. There's no standard for that value, which is why it often creates problems.

Opus 1.1

Reply #48 –
When data length cannot be predicted, some placeholder value has to be written anyway as the length of data chunk. Some use maximum 32bit signed/unsigned integer value, and ffmpeg uses zero.
When actual number of samples is shorter than the value computed from placeholder value, it is OK. However, in ffmpeg case, the receiver usually needs to ignore the size field of the data chunk.
If opusenc doesn't work even with --ignorelength, maybe ignorelength switch isn't working as expected.

As for qaac, qaac -D is just a PCM output mode. It read from whatever input format supported by qaac and writes PCM, by default in WAV format.

Opus 1.1

Reply #49 –
Found a way to fix this problem: in function seek_forward (in audio_in.c) comment out fseek():

Code: [Select]
static int seek_forward(FILE *in, unsigned int length)
{
    //if(fseek(in, length, SEEK_CUR))
    {
        /* Failed. Do it the hard way. */
        unsigned char buf[1024];
        unsigned int seek_needed = length;


added: currently opusenc uses fseek() to skip over "LIST"  chunk, and this somehow prevents further reading/seeking