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.
Recent Posts
3
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Case -
Very initial HALAC input component for foobar2000: https://foobar.hyv.fi/foo_input_halac.fb2k-component.

Couple of warnings:
The input library is very basic and only supports loading files by file path, and the path is given in ANSI codepage so characters needing unicode won't work.

As the library forces decoding the entire file to memory large files will need a lot of RAM. But the library won't be able to handle very big files as it addresses size with 32-bit integer.

The library doesn't seem to have any error checking. Feeding it a path that doesn't exist makes the host program (foobar2000) crash. Trying to load corrupted/invalid HALAC file makes the host program crash.

Edit: and based on the DLL name I believe AVX is required. And since there is only 64-bit DLL available this version of the component only works on 64-bit foobar2000.
4
Opus / Re: Opus v1.5.2
Last post by Marsu42 -
Quote from: jdimsa on
Is there any reason to stick to multiples of 16/32 for target bitrate in opus encoder or does it not matter? I noticed qaac/Apple AAC forces 112-128-160-192 etc.

Opus does have some built-in bitrate thresholds that affect how it encodes - some, but not all of of these are at 16kbps multiples, probably for historical reasons.
https://wiki.xiph.org/Opus_Recommended_Settings#Bandwidth_Transition_Thresholds
https://github.com/xiph/opus/blob/main/src/opus_encoder.c
6
General Audio / Re: Tested: codecs vs battery life on Android telephones
Last post by Marsu42 -
Quote from: Nick.C on
https://www.rockbox.org/wiki/CodecPerformanceComparison

The rockbox comparison reminds of that Opus isn't one codec, but two - SILK and CELT, supporting three modes - which probably shouldn't randomly tested together. https://wiki.xiph.org/OpusFAQ#Why_not_keep_the_SILK_and_CELT_codecs_separate?

Low bitrate Opus decoding seems to be significantly faster (i.e. should use less power for the same job), probably due to SILK or hybrid mode being used?

On the other hand, modern Opus with LACE/noLACE post-processing on high decoding complexity settting is probably a lot worse performance-wise - but makes up for that by significant enhancement in <16kbps quality.
8
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Kraeved -
@mudlord, Hakan understood me perfectly, but you didn’t, alas. Okay, I can elaborate.

HALAC is designed for people. It is constantly compared with other tools that people use in order to highlight its superiority. It was never limited to the author’s fun, internal use, or, say, participation in the Informatics Olympiad.

When you make a project for people, then people inevitably provide feedback. It ranges from admiration to frustration, and in between there are questions and suggestions. Thanks to this feedback, projects develop further. If this is not obvious to you, then look at issue trackers and forums of the well-known apps. For example, Peter added OGG chapters support to Foobar2000 because I asked about it and then he recompiled it because other users complained about a crash while calculating ReplayGain values on systems without AVX. If you are not ready to process feedback or even do not need it, then make it clear in the first place. For example, disable the issue tracker on Github. It's that simple.

Hakan and I talked about priorities: a) SSE2/3 version enables more users to benefit from the tool and b) users need not only to encode, but also to listen to the material, otherwise the benefits of the tool are more visible on the charts than in real life. The author agreed that there was a reasonable grain in this appeal.
10
General Audio / Can ALAC/m4a detect file corruption?
Last post by shitdarling -
I have found amount of article, and know that flac/ape/tak can check audio integrity with inner crc info and outter md5.
ALAC/m4a is also open. But its format is so complicated (so many "box" type with different meta info), and I try to find crc or md5
in the format  structure detail description, and cant find them.

I have tried use an hex editor directly change some random bytes in middle of the alac file.
First time I change 2 position, [foobar 2000 - verify integrity] says it's ok. So the check tool cant detect this change.
Second time I change 2 more position, and this time the tool report :
"Reported length is inaccurate : 4:25.653333 vs 4:25.560454 decoded
Error: Decoding error: Unsupported format or corrupted file, frame: 2112 of 2861".

May there anyone know much about ALAC/m4a structure could tell me :
Can ALAC/m4a detect file corruption? (with inner metadata like crc/md5?or other mechanism?) O:)