11
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.
12
Uploads / Re: FLAC (subset) file that ffmpeg (7.0, Windows) cannot decode
Last post by mycroft -13
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by mycroft -14
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by Porcus -ffmpeg -threads 1 DEcodes much faster than the reference, which takes 42 percent more time. Tested the half-hour long file, mean of repeated runs:
533x realtime: DEcoding by ffmpeg -threads 1
375x realtime: DEcoding by tta.exe
ffmpeg also ENcodes faster, but there the difference is small. 451x realtime vs 423x realtime.
Everything to NUL.
15
Opus / Re: Opus decoding complexity
Last post by 2012 -@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!
16
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Kraeved -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.
Monkey Audio, WavPack and NeroAAC report it was pressed:
a) Ctrl+C: MAC has been interrupted !!!
b) creating in.wv, 7% done...^C (that ^C is something, but not user-friendly)
c) Interrupted at 27 seconds... (27 seconds of what? Not the encoding time, but the source time)
WavPack does not leave an incomplete file.
Lossy encoders.
Code: [Select]
$ exhale 9 in.wav in.m4a
exhale - ecodis extended high-efficiency and low-complexity encoder
version 1.2.1 (x64, built on Dec 20 2023) - written by C.R.Helmrich
Encoding 44-kHz 2-channel 16-bit WAVE to low-complexity xHE-AAC at 192 kbit/s
Progress: --
$ faac in.wav
Freeware Advanced Audio Coder FAAC 1.30
Initial quantization quality: 100
Average bitrate: 64 kbps/channel
Bandwidth: 19293 Hz
PNS level: 4
Object type: Low Complexity(MPEG-2) + IS + PNS
Container format: Transport Stream (ADTS)
Encoding in.wav to in.aac
frame | bitrate | elapsed/estim | play/CPU | ETA
2150/24275 ( 8%)| 133.6 | 0.7/8.3 | 68.11x | 7.5
$ fdkaac -m5 in.wav
[3%] 00:14.838/09:23.627 (21x), ETA 00:26.297
654336/24855936 samples processed in 00:00.711
$ fhgaacenc in.wav
Progress: 7%
$ lame in.wav
LAME 3.101 (beta 3, Dec 16 2023) 64bits
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding in.wav to in.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
400/21578 ( 2%)| 0:00/ 0:24| 0:01/ 0:53| 22.864x| 0:52
--09:13------------------------------------------------------------------------
kbps LR MS % long %
128.0 64.8 35.2 100.0
$ lossywav in.wav
lossyWAV 1.4.2, Copyright (C) 2007-2016 Nick Currie. Copyleft.
Filename : in.wav
Settings : --quality standard
File Info : 44.10kHz; 2 channel; 16 bit; 09:23.62, 94.81MiB
Progress : 2.11%; 1.2178 bits; 15.74x; 00:00.76/00:35.81
$ mpcenc in.wav
MPC Encoder 1.30.0 --stable-- (C) 1999-2009 Buschmann/Klemm/Piecha/MDT
encoding file 'in.wav'
to file 'in.mpc'
SV 8, Profile 'Standard'
%|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
7.4 164.1 kbps 26.94x 0:41.5 9:23.6 0:01.5 0:20.9 0:19.3
$ neroaacenc -if in.wav -of in.m4a
Nero AAC Encoder
Package build date: Feb 18 2010
Package version: 1.5.4.0
Interrupted at 27 seconds...
$ oggenc in.wav
Opening with wav module: WAV file reader
Encoding "in.wav" to
"in.ogg"
at quality 3,00
[ 2,0%] [ 0m48s remaining] \
$ opusenc in.wav in.opus
Encoding using libopus 1.5.2-2-gdfd4175 (audio)
-----------------------------------------------------
Input: WAV, 44.1 kHz, 2 channels, stereo
Output: Opus, 2 channels (2 coupled), stereo
20ms packets, 96 kbit/s VBR
Preskip: 312
[|] 10% 00:01:00.12 20x realtime, 95.94 kbit/s
$ qaac in.wav
qaac 2.82, CoreAudioToolbox 7.10.9.0
in.m4a
AAC-LC Encoder, TVBR q91, Quality 96
[2.9%] 0:16.370/9:23.626 (21.0x), ETA 0:26.075
721920/24855936 samples processed in 0:00.780
Overall bitrate: 201.654kbps
Optimizing...done
$ qoa in.wav in.qoa
in.wav: channels: 2, samplerate: 44100 hz, samples per channel: 24855936, duration: 563 sec
Lossless encoders.
Code: [Select]
$ flac -7 in.wav
flac git-d2b24410 20240309
in.wav: 9% complete, ratio=0,512
$ 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 !!!
$ takc -e in.wav
in.wav ...
$ tta -e in.wav in.tta
TTA1 lossless audio encoder/decoder, version 2.3
Encoding: "in.wav" to "in.tta"
Progress: 20%
$ wavpack -x3m --threads in.wav
WAVPACK Hybrid Lossless Audio Compressor Win64 Version 5.7.0
creating in.wv, 7% done...^C
17
Audio Hardware / Re: audio device on Beelink u59 / AZW U59 (U3E1)
Last post by stanley.tweedle -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.
Thank you, cordially!
18
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Case -19
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Kraeved -I added the SSE2 version of DLL to Github.
@Case, please, update your Foobar2000 component accordingly.
20
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Case -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.