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.
@saratoga Looks like you're wrong. I did the decoding speed test myself and MP3 was way faster than Opus.
Different devices (and software environments) have different capabilities and properties. The same applies to decoders.
On the sort of device where this would become a concern, a fixed-point Opus decoder is used (possibly with extra optimizations applied). On a PC, a floating-point Opus decoder (slower, but more accurate) is often used.
libopus offers both variants. A native Opus decoder exists in FFmpeg too which is maybe floating-point only (not sure).
There are many MP3 decoders out there.
Not sure which decoders would have been used in your test.
Quote
Edit: Both are 16kbps.
Opus is basically two codecs in one, SILK and CELT. One of the two, or a hybrid, is maybe used internally. At 16kbps, SILK (optimized for low-bitrate voice content) was probably used. Hybrid is a possibility too depending on input parameters and content. In any case, that test is not sufficient.
------
The way you're approaching this almost give the impression that you're trying to solve a puzzle or answer a pop quiz question. Maybe defining a practical use-case, testing for it, then asking questions if any arise, would be a better and more fruitful approach!
If there is a help text about Ctrl+C for interrupting then the program will also need a signal handler for the interruption. Otherwise Ctrl+C will just terminate the process hard leaving the output file in invalid state with incorrect headers.
I compared the behavior of different encoders when pressing Ctrl-C combo. Only Monkey Audio and WavPack report it was pressed and only WavPack does not leave an incomplete file. QAAC was quite misleading because it rushed to optimize an incomplete file with a promising “Done” at the end.
$ mac in.wav auto -c2000 --- Monkey's Audio Console Front End (v 10.61) (c) Matthew T. Ashland --- Compressing (normal)... Progress: 8.3% (10.7 seconds remaining, 1.0 seconds total) Ctrl+C: MAC has been interrupted !!!
Last post by stanley.tweedle -
It's so unnerving I always forget. The audio device actually works "fine" when I boot into Linux. There's still issues. I hesitate to ever buy a product from that manufacurer again. I hate to say that because I'm just not the type of person to go around trying to dis' on someone. I'm from way back when you could fit 6 hard drives in the case! the old IDE kind. but stuff worked back then somehow. my fingers can barely get the screws out to swap the SSD on occasion. haha. We made some pretty bad-ash recordings with this Event Electronics GINA though. I think it was 16bit 44.1k?
From my professional experience, albeit twenty years ago by now, you're always going to get a better sound from outboard gear, even if the processor isn't being taxed because it's simply what it's made for. quality outboard gear (e.g. ad/da conversion processes) makes for night and day of course! Cables etc. When Windows tries to use it, it sounds like there's broken wires on the INSide! Obviously, it comes down to not being able to afford the proper gear at this time. So, I'm writing as much to hear myself say it.
I would say Linux powers it in fairly high fidelity. I personally never liked the way any audio sounds on Linux. Never studied it.
Last post by Case -
If there is a help text about Ctrl+C for interrupting then the program will also need a signal handler for the interruption. Otherwise Ctrl+C will just terminate the process hard leaving the output file in invalid state with incorrect headers.
Last post by Case -
Best option for API would be not to rely on filenames at all. Most libraries allow setting callback functions - you just give pointer to simple functions for reading and seeking and other features API might need. Another option would be to use memory pointers for data exchange.
Not relying on filenames would for example mean that foobar component would automatically get support for playing HALACs over internet and from archives. And features like full file buffering or prebuffering parts of future tracks would work.
And partial decoding is of course very important for realtime playback. Decoding entire track in advance not only requires way too much memory, but it can also means a long delay for track changes potentially breaking gapless playback.
For playback use it would also make sense to have some way to report the audio data specs to the player and just give the audio data to it. My component now includes parser for WAV, RF64, BW64 and W64 formats just in case such things pop out of HALAC so that it can play them. It's not nice to outsource these things for the player.
Oh yeah, and you should specify what calling convention the functions use. Now they seem to depend on compiler defauls.
EZ CD Audio Converter 11.0.3 now includes the new Fraunhofer IIS xHE-AAC encoder v4.4.0 with audio quality improvements
The term "audio quality improvements" isn't very detailed, ant the EZ CDDA version history just states "Updated Fraunhofer IIS xHE-AAC encoder v4.4.0" - does anyone happen to know what the actual xHE-AAC improvements are, on voice or music encoding?
Removing kbhit is something I also wanted to suggest. There's CTRL+c for that.
We can replace the interrupt by any key with Ctrl-C, but I believe we should keep the hint on the screen, separate it with an empty line, and remove < >.
Last post by maikmerten -
Removing kbhit is something I also wanted to suggest. There's CTRL+c for that, and I think that one works across platforms and doesn't involve querying input via syscall.