http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml (http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml) Dated as yesterday (2013-12-04), the URL will probably be updated.
http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/)
https://ftp.mozilla.org/pub/mozilla.org/opus/win32/ (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/) (thanks o-l-a-v)
opustools 0.1.8 (using libopus 1.1) x86 by mozilla (05.12.13)
https://ftp.mozilla.org/pub/mozilla.org/opus/win32/ (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/)
I just did a decoding speed test between Vorbis and Opus. Vorbis has around 1150x and Opus around 200x. Why so much difference and how much can the difference bother the battery life of a device?
AAC is also around 1500x and MP3 around 850x. Of course it depends on the CPU etc but is this low decoding speed symptom of inefficiency? Please correct me if it's wrong and again correct me if 200x is not considered low. How low is considered low with a new generation processor?
http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml (http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml) Dated as yesterday (2013-12-04), the URL will probably be updated.
http://www.opus-codec.org/downloads/ (http://www.opus-codec.org/downloads/)
https://ftp.mozilla.org/pub/mozilla.org/opus/win32/ (https://ftp.mozilla.org/pub/mozilla.org/opus/win32/) (thanks o-l-a-v)
Considering that we're still working through the announcement, binaries and webpage updates, ... this is
not officially released. It's a bit rude to rush this kind of announcement before we've even had time to announce ourselves or even checked that all files are what they're supposed to be. It also means next time we'll have to to through the trouble of hiding all these files.
Considering that we're still working through the announcement, binaries and webpage updates, ... this is not officially released. It's a bit rude to rush this kind of announcement before we've even had time to announce ourselves or even checked that all files are what they're supposed to be. It also means next time we'll have to to through the trouble of hiding all these files.
You're right, pardon about that. Can a mod please remove "Officially Released" from the 2nd line of the title of this thread?
With "Officially" I was only trying to say the new source is available, I didn't think it through. And again, I only do this because I get excited with new updates and features and I can't wait for everyone to start testing.
Thank you for the update.
o-l-a-v where did U get opus tools 0.1.8? The referenced link seems to be dead:
http://downloads.xiph.org/releases/opus/op...ls-0.1.8.tar.gz (http://downloads.xiph.org/releases/opus/opus-tools-0.1.8.tar.gz)
I just did a decoding speed test between Vorbis and Opus. Vorbis has around 1150x and Opus around 200x. Why so much difference and how much can the difference bother the battery life of a device?
AAC is also around 1500x and MP3 around 850x. Of course it depends on the CPU etc but how can be Opus considered a last generation codec if it's so inefficient? Please correct me if it's wrong to think that low decoding speed is symptom or inefficiency and again correct me if 200x is not considered low. How low is considered low with a new generation processor?
We have discussion about decoding speed here http://www.hydrogenaudio.org/forums/index....st&p=817600 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=96981&view=findpost&p=817600)
Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%
Also there are 3 variables: quality, complexity and delay. It's hard to increase some of them without decrease another one(s).
While Opus is somewhat more complex it's a high quality codec and ... still low-delay.
Speaking of quality, even 1.1 still doesn't hit a full potential of format and but it will be interesting to see how Opus now performs against the best encoders around here.
A similar situation has happened with H.264 10 years ago. It consumed more power than previous gen video format.
Some companies like DivX didn't want to adopt it and had pushed their DivX ASP format instead telling that ASP is less complex. Later they have realized they were too late and have bought a Mainconcept that had H.264 implementation. And now they are one of the first to implement H.265 .
I just did a decoding speed test between Vorbis and Opus. Vorbis has around 1150x and Opus around 200x. Why so much difference and how much can the difference bother the battery life of a device?
AAC is also around 1500x and MP3 around 850x. Of course it depends on the CPU etc but is this low decoding speed symptom of inefficiency? Please correct me if it's wrong and again correct me if 200x is not considered low. How low is considered low with a new generation processor?
How are you testing this, BTW?
You aren't comparing an SSE/SSE2/SSE3/SSE3/AVX/AVX2 optimized MP3/AAC decoder on a PC supporting all of those, against the Opus reference code with only ARM optimizations, are you? That would be a rather very silly thing to do and draw conclusions from.
We have discussion about decoding speed here http://www.hydrogenaudio.org/forums/index....st&p=817600 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=96981&view=findpost&p=817600)
Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%
Also there are 3 variables: quality, complexity and delay. It's hard to increase some of them without decrease another one(s).
While Opus is somewhat more complex it's a high quality codec and ... still low-delay.
Speaking of quality, even 1.1 still doesn't hit a full potential of format and but it will be interesting to see how Opus now performs against the best encoders around here.
A similar situation has happened with H.264 10 years ago. It consumed more power than previous gen video format.
Some companies like DivX didn't want to adopt it and had pushed their DivX ASP format instead telling that ASP is less complex. Later they have realized they were too late and have bought a Mainconcept that had H.264 implementation. And now they are one of the first to implement H.265 .
Got it, thank you.
How are you testing this, BTW?
You aren't comparing an SSE/SSE2/SSE3/SSE3/AVX/AVX2 optimized MP3/AAC decoder on a PC supporting all of those, against the Opus reference code with only ARM optimizations, are you? That would be a rather very silly thing to do and draw conclusions from.
I did that too, encoding is much faster in optimized builds obviously but decoding is the same.
I did that too, encoding is much faster in optimized builds obviously but decoding is the same.
You did what too? What did you do? What did you compare? Which AAC decoder on what platform? What AAC version? LC? HE-AAC? HE-AACv2? Which MP3 decoder on what platform? Which Opus decoder on what platform?
Edit: Clarified the question even more.
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.
Opus 1.1 x86-32, Vorbis x86-32 libopus 1.3.3, Vorbis x86-32 aoTuV, Vorbis x86-32 aoTuV-SSE3 Optimized, Apple AAC 7.9.8.3, LAME 3.99.5 x86-32, LAME 3.100a2 x86-32.
IgorC explained what I needed to know.
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.
The numbers you report are implausibly high (several times higher than my Intel Xeon workstation in fact), which suggests that you are probably looking at multithreaded x86 performance, which is basically meaningless in this context.
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.
Opus 1.1 x86-32, Vorbis x86-32 libopus 1.3.3, Vorbis x86-32 aoTuV, Vorbis x86-32 aoTuV-SSE3 Optimized, Apple AAC 7.9.8.3, LAME 3.99.5 x86-32, LAME 3.100a2 x86-32.
If you're using foobar2000 and the decoding test component, you're not using the decoders you list, but at best the encoders. For decoding it will use foobar2000's internal decoder for AAC, MP3 and Vorbis, which is ffmpeg-2.1 (IIRC), which in turn is extremely heavily optimized to use SSE/SSE2/.../AVX/etc. It will not use ffmpeg for Opus, because ffmpeg has no internal Opus decoder yet. It will use the reference decoder, which only has optimizations for ARM, which is not what you're running it on! It is however, what a battery powered phone or tablet will run on.
So yeah: you're comparing an extremely optimized decoder having had 13 years of optimization and using all CPU features with a reference one that's optimized for another platform.
(You also compared LC-AAC instead of HE-AAC or HE-AACv2, which doesn't really make sense for bitrates lower than about 80kbps, but that's another discussion)
The numbers you report are implausibly high (several times higher than my Intel Xeon workstation in fact), which suggests that you are probably looking at multithreaded x86 performance, which is basically meaningless in this context.
No, ffmpeg's decoders can do this single-threaded. They're insanely fast on a system with all the latest SSE/AVX stuff. If your Xeon has one less revision of AVX than his, performance will already cut in half, though.
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.
The numbers you report are implausibly high (several times higher than my Intel Xeon workstation in fact), which suggests that you are probably looking at multithreaded x86 performance, which is basically meaningless in this context.
I think the numbers are ok. The last foobar version had an insanely optimizied decoders, ffmpeg.
I just did it, like half an hour ago using just foobar2000 and the Decoding Speed Test component.
The numbers you report are implausibly high (several times higher than my Intel Xeon workstation in fact), which suggests that you are probably looking at multithreaded x86 performance, which is basically meaningless in this context.
I think the numbers are ok. The last foobar version had an insanely optimizied decoders, ffmpeg.
The vorbis decoder is actually libvorbis, not ffmpeg, at least in 1.3 beta 6's credits. If hes getting 1500x single threaded for 128k, then hes running the equivalent of a ~6GHz Xeon which seems unlikely
I tested in rockbox on the Clipv2 (ARM9E) w/ 24 MHz RAM clock:
Opus 64k:51.24 MHz
Opus 128k: 58.09 MHz
Vorbis 128k: 48.45 MHz
Rockbox was synced to git a couple months ago, so its a bit behind, but probably pretty close to current release minus a few optimizations.
You may also try this optimized opus tools 0.1.8 which should be quite fast on all configurations:
- finally flac support added
- encoded range still doesn't match range_working exactly but is close to it, and as it looks official make from Mozilla neither does
http://www.datafilehost.com/d/4cec750c (http://www.datafilehost.com/d/4cec750c)
Hopefully there's no more problem with artifacts
Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%
FIrst, there are a lot more ARM players than just smart phones. I think mine is 2 core 80 mhz.
Second, on a phone there will be other stuff going on than just decoding Opus, and you still want the CPU to go as low as it can.
Third, if I'm playing music on a phone and not diddling around with the controls, it's in sleep mode with the display off for the duration of the playlist/album.
BTW, my likely next phone uses Opus as the default codec for calls.
Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%
FIrst, there are a lot more ARM players than just smart phones. I think mine is 2 core 80 mhz.
I don't know what people prefer in another countries but where I live there are much more people who use smartphone to listen to music rather than media players.
And each time there are less people who use DAP. I remember the 2000-2007 years, allmost everybody used DAPs. Popularity of DAPs is minimal nowdays.
Second, on a phone there will be other stuff going on than just decoding Opus, and you still want the CPU to go as low as it can.
I don't see how 30-40 MHz can do any difference, let's say on on 2x1200 MHz ARM CPU. In my experience I got 18 hours of audio playback on my smartphone with a dual Cortex A9 1.2 GHz. I don't get any benefit to use a lighter audio codec because my battery ends way faster than that with intensive display+cpu+wi-fi use.
Third, if I'm playing music on a phone and not diddling around with the controls, it's in sleep mode with the display off for the duration of the playlist/album.
And You will get a long battery life with Opus in that mode anyway.
Shortly, a smartphone's processors can go lower than 200 MHz in idle mode hence there won't much gain in battery life. Plus display consumes more power than CPU in mobile devices.
Testing on desktop PC has even less sense. 200x isn't enough? It is less than 1%
FIrst, there are a lot more ARM players than just smart phones. I think mine is 2 core 80 mhz.
Well, then yours is probably a portal player based device, which hasn't been on the market in 7 years
But yes, a little more optimization is needed for older devices. I may try to look into this over the holidays if I can find the time.
I don't know what people prefer in another countries but where I live there are much more people who use smartphone to listen to music rather than media players.
And each time there are less people who use DAP. I remember the 2000-2007 years, allmost everybody used DAPs. Popularity of DAPs is minimal nowdays.
The reasons I still use my player from that era are the microSD slot and replaceable battery.
Though my current phone has those, it is tough getting through a whole day on a charge while I typically go a week on the DAP. I must say that Opus decoding is not a significant factor on phone battery unless I don't try to use it as a phone. THe cell radio (which I could disable) will suck the battery dry in a few hours of "idling" if I'm in a weak coverage area.
There's an April time stamped build of Opus available on Rarewares which identifies itself as libopus 1.1.x-git in the encoded opus files.
What kind of improvements this build holds compared to the standard libopus 1.1 build?
There's an April time stamped build of Opus available on Rarewares which identifies itself as libopus 1.1.x-git in the encoded opus files.
What kind of improvements this build holds compared to the standard libopus 1.1 build?
I'd like to know too. Assume those changes are only minor/cosmetic and don't bring any substantial codec step up, otherwise it would be tagged a new verion and announced at http://www.opus-codec.org/ (http://www.opus-codec.org/)
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 (http://git.xiph.org/?p=opus.git;a=shortlog)
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 (http://git.xiph.org/?p=opus.git;a=shortlog)
And RareWare's version is also half the speed encoding.
And RareWare's version is also half the speed encoding.
Did you mean twice the speed?
Did you mean twice the speed?
It encoded in double the time, sorry yes it's slower.
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
Anakunda thanks, can you make a build with the DLLs inside the .exe?
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`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!
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.
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.
Only works with Intel CPUs. I have a AMD A10-5800K APU and it refuses to execute on it.
Are RareWares' builds (http://www.rarewares.org/opus.php (http://www.rarewares.org/opus.php)), that are the same "latest 1.1 git", compatible with AMD? They should work.
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/ (http://www.opus-codec.org/downloads/)
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.
opusenc.exe accepts 32bit float directly:
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):
avs2pipemod.exe -wav input.avs | opusenc.exe (--bitrate 64) - output.opus
But opusenc.exe
doesn't accept 32bit float through pipe from ffmpeg.exe:
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:
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?
It somehow doesn't accept ffmpeg's wav headers
ffmpeg doesn't output WAV headers with your settings.
Try:
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.
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.
Well, this approach with "-acodec pcm_f32le -f wav" works with lame, wavpack and qaac and doesn't work with oggenc2 and opusenc. Interesting...
Then I'm interested to see what NullC and/or jmvalin has to say about it.
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.
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 :
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.
I don't have Apple software installed, so I can't use qaac
Of course you can, in portable mode. Download makeportable here: https://sites.google.com/site/qaacpage/cabinet (https://sites.google.com/site/qaacpage/cabinet)
I don't have Apple software installed, so I can't use qaac
QAAC Homepage (https://sites.google.com/site/qaacpage/)
QuickTime installation is no more required. Nov 9, 2011
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:
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.
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.
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.
Found a way to fix this problem: in function seek_forward (in audio_in.c) comment out fseek():
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
Found a way to fix this problem: in function seek_forward (in audio_in.c) comment out fseek():
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
Doesn't it look familiar? IIRC, I saw similar code in flac frontend in the past.
fseek() on a non-seekable file is guaranteed to fail on Posix, but not on Windows. Therefore, "try to seek first and read when fail" doesn't work...
So another solution is to use #ifdef?
static int seek_forward(FILE *in, unsigned int length)
{
#if !defined _WIN32
if(fseek(in, length, SEEK_CUR))
#endif
{
/* Failed. Do it the hard way. */
unsigned char buf[1024];
So another solution is to use #ifdef?
static int seek_forward(FILE *in, unsigned int length)
{
#if !defined _WIN32
if(fseek(in, length, SEEK_CUR))
#endif
{
/* Failed. Do it the hard way. */
unsigned char buf[1024];
I have uploaded a build of opustools with this mod in place. If someone would kindly confirm this works OK, I'll complete other relevant recompiles and upload.
It's available here: http://www.rarewares.org/files/opus/opus-t...win32_SSE-1.zip (http://www.rarewares.org/files/opus/opus-tools-0.1.8-win32_SSE-1.zip)
TIA.
This one works, john33.
ffmpeg.exe -hide_banner -i input.avs -c:a copy -f wav - | qaac.exe --silent -D - -o - | opusenc.exe --bitrate 64 - output.opus
ffmpeg.exe -hide_banner -i input.avs -c:a copy -f wav - | opusenc.exe --bitrate 64 - output.opus
Now both produce the same output. Thank you, lvqcl and john33!
Upon having loaded the AviSynth audiostream ffmpeg does still notify me though with: "[wav @ 02f8d700] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead." Does anyone know by chance if this is important/bad?
Btw john33, I see you grabbed opus-tools 0.1.8 for this fix, but 0.1.9 is out already.
This one works, john33.
........
Btw john33, I see you grabbed opus-tools 0.1.8 for this fix, but 0.1.9 is out already.
Thanks for the feedback, and the 'heads up'. I'll sort new compiles out tomorrow.
This one works, john33.
........
Btw john33, I see you grabbed opus-tools 0.1.8 for this fix, but 0.1.9 is out already.
Thanks for the feedback, and the 'heads up'. I'll sort new compiles out tomorrow.
Opus-tools updated on Rarewares to 0.1.9, including the bug fix. I'll get to the oggenc2 compiles later.
Opus-tools updated on Rarewares to 0.1.9, including the bug fix.
Thanks.
I'll get to the oggenc2 compiles later.
What's new on this one? Same fix?
opusenc.exe -V
opusenc opus-tools (using libopus 1.1.x-git)
Copyright (C) 2008-2013 Xiph.Org Foundation
Could you please recompile and enter the opus-tools version, because opusinfo.exe, but especially MediaInfo reads those entries.
"libopus 1.1.x-git" means compiled from latest git at that moment I guess?
P.s. http://www.rarewares.org/opus.php (http://www.rarewares.org/opus.php) --> you seem to forgot a "<" in front of "/span>".
I'll get to the oggenc2 compiles later.
What's new on this one? Same fix?
Yep.
opusenc.exe -V
opusenc opus-tools (using libopus 1.1.x-git)
Copyright (C) 2008-2013 Xiph.Org Foundation
Could you please recompile and enter the opus-tools version, because opusinfo.exe, but especially MediaInfo reads those entries.
"libopus 1.1.x-git" means compiled from latest git at that moment I guess?
P.s. http://www.rarewares.org/opus.php (http://www.rarewares.org/opus.php) --> you seem to forgot a "<" in front of "/span>".
Recompiled, as requested. Sorry, I thought I'd taken care of that! Yes, latest git.
opus.php fixed as well, thanks again!
Appreciated, thanks!
I was wondering btw...will this fix only be in your binaries, or also in futures releases on http://opus-codec.org (http://opus-codec.org)?
Appreciated, thanks!
I was wondering btw...will this fix only be in your binaries, or also in futures releases on http://opus-codec.org (http://opus-codec.org)?
Only in mine until jmvalin, or another official maintainer, makes the change.
You can steel fskip_ahead() from FLAC frontend:
https://git.xiph.org/?p=flac.git;a=commitdi...6a8645e83be9768 (https://git.xiph.org/?p=flac.git;a=commitdiff;h=0da96d3cfd13931439324785ca1b89bb788a4a49;hp=55788ea96b6f71300bccfee2e6a8645e83be9768)
LAME has similar function named fskip() in get_audio.c, in which only S_ISFIFO is treated as a non-seekable candidate.
Completely killing fseek() on win32 is usually fine since what is skipped is usually tiny.
However, AIFF can have COMM(=header) after ssnd(=PCM data), in which case HUGE amount of block has to be skipped by fread() before reading COMM.
You can steel fskip_ahead() from FLAC frontend:
https://git.xiph.org/?p=flac.git;a=commitdi...6a8645e83be9768 (https://git.xiph.org/?p=flac.git;a=commitdiff;h=0da96d3cfd13931439324785ca1b89bb788a4a49;hp=55788ea96b6f71300bccfee2e6a8645e83be9768)
LAME has similar function named fskip() in get_audio.c, in which only S_ISFIFO is treated as a non-seekable candidate.
Completely killing fseek() on win32 is usually fine since what is skipped is usually tiny.
However, AIFF can have COMM(=header) after ssnd(=PCM data), in which case HUGE amount of block has to be skipped by fread() before reading COMM.
Code 'stolen' from FLAC fronted! Could someone kindly check that I've amended this in a way that it performs correctly? TIA.
It's here: http://www.rarewares.org/files/opus/opus-t...win32_SSE-1.zip (http://www.rarewares.org/files/opus/opus-tools-0.1.9-win32_SSE-1.zip)
Piping 32bit float AviSynth audio from ffmpeg to opusenc works for me. Thanks.
Piping 32bit float AviSynth audio from ffmpeg to opusenc works for me. Thanks.
Excellent. Thanks for letting me know. I'll proliferate new compiles that use this code.
john33, thanks for the new builds again.
Is SSE2 optimised instead of SSE on Opus 64bit a typo?
john33, thanks for the new builds again.
Is SSE2 optimised instead of SSE on Opus 64bit a typo?
No, it's not a typo, I just selected the SSE2 compiler option on all the Opus x64 component builds.
eahm, all x64 CPUs must support SSE2, so there's no harm....
eahm, all x64 CPUs must support SSE2, so there's no harm....
True.
Even the very first 64-bit Athlons (ClawHammer and Newcastle from september 2003) already had SSE2 support. So there's no 64-bit desktop CPU from Intel or AMD without SSE2.
2 john33: thanks for releasing new opus builds. Btw do you still plan to create opusdropXP one day ?
ffmpeg does still notify me though with: "[wav @ 02f8d700] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead." Does anyone know by chance if this is important/bad?
Hi
It's been fixed ---> fixed (https://trac.ffmpeg.org/ticket/3741)
Confirmed, thank you.
Why file converted 2 times with same encoder options (--bitrate 128) with last official codec opus-tools 0.1.9 they have different structure/checksum?
(http://i.imgur.com/5NdlVsZ.jpg)
Why file converted 2 times with same encoder options (--bitrate 128) with last official codec opus-tools 0.1.9 they have different structure/checksum?
Timestamp? Unique conversion id?
Diagnostic options:
--serial n Forces a specific stream serial number