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
31
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by Porcus -
@bryant on WavPack:
Whether wvunpack --threads=<N> vs ffmpeg -threads=<N> is apples to apples ... I don't know. It might be "better" than comparing wvunpack --threads vs ffmpeg (spawning all), and all I could do was to get it down to thread count matters enough to tilt the numbers.


@ktf on FLAC:
Sure if we could just pick up some magic and speed up stuff. Anyway I made a mess out of it, first time I was not sure whether ffmpeg -threads 1 meant "single thread" or "one worker in addition to the bookkeping/parsing", so is part of my lame excuses.
But:
I got something that you could maybe speed up for: it seems 1.3.x does small blocks faster than 1.4.x. Since I got this wrong AND didn't stay completely consistent on which flac executable I used, I ran it together with a test to see when ffmpeg stops making a fool of itself (it was at block sizes below reference's -0/-1/-2, that is good):

What I did: explained over in the FLAC test thread: https://hydrogenaud.io/index.php/topic,123025.msg1044103.html#msg1044103 With more diagrams, including 1.2.1. And encoding.

Anyway, ffmpeg starts behaving "more normal" at "normal" block sizes.
For reference flac it might look surprising that -5 and -0 make so little difference. But most of the graph is for (too!) small block sizes, and apparently the time penalty for processing those, override the calculation job.




@mycroft :
"seditious" sounds like you just learned a new bad word and is waiting to use it ... couldn't you be constructive and educate instead?
For better or for worse, FLAC's design is frozen long ago, and for now it stays the biggest player in the lossless audio files market, at least disregarding silver discs.
But good that you actually contribute repairing bad code, and not only whine toxicity.
32
3rd Party Plugins - (fb2k) / Re: foo_enhanced_spectrum_analyzer
Last post by TF3RDL -
Quote from: TF3RDL on
@Crossover, what about non-power of two FFT sizes like 4800 samples (100ms at 48kHz samplerate)?
Feature request: Being able to set FFT size to specified length in milliseconds instead of samples as get_chunk_absolute() in fb2k SDK takes length in seconds rather than in samples

This makes the window length in seconds/milliseconds samplerate-independent when you set the unit for "FFT size" to milliseconds
33
Polls / Re: 2024 Format Poll [Lossy/Semi-Lossy]
Last post by guruboolez -
WavPack is missing. You should add it.
You should also remove VQF, Real Audio, SBC, Encodec, MP1 and MP2: they are nonsensical in 2024. If you really need to offer an exhaustive overview of vintage formats, check https://www.rarewares.org/rrw/programs.php and give to Mafuka a chance ;)
xHE-AAC is different from AAC (LC and HE), I would make a different entry for it.


EDIT: I would also remove WMA: 0 vote in 2016
https://hydrogenaud.io/index.php/topic,112400.0.html

EDIT2: there's already a 2024 lossy poll:
https://hydrogenaud.io/index.php/topic,125552.0.html
34
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Porcus -
You could of course have a quick look at whether HALAC could be used in conjunction with LossyWAV. Then those who are interested in lossy (+ correction files) could play around with it and see if something interesting comes up near the speed/quality frontier. I surely agree with you (though it is your say and not mine) that creating a new lossy codec need not be next week's project.

BTW, @Nick.C the LossyWAV developer: Your profile page has the ancient LossyWAV 1.3.0 development thread as your homepage ... did anyone notice in the 1/8th of a century since it was locked?   :))
35
3rd Party Plugins - (fb2k) / Re: foo_midi (foobar2000 v2.0)
Last post by pqyt -
v2.10.0.0, 2024-05-07, It's been a while

* New: The volume of BASS MIDI can be tweaked independently of the overall volume. Defaults to 0.15, determined experimentally to align with the other players.
* Improved: Added detection of EUC-JP encoded meta data.
* Improved: Added Shift-JIS and EUC-JP detection and conversion for lyrics.
* Fixed: Mixed ANSI and Shift-JIS wasn't detected (anymore?).
* Fixed: The BASS MIDI voice count was not initialized correctly when using a preset.
* Fixed: Emu de MIDI sysex recognition.
* Fixed: Emu de MIDI potential buffer overflow during rendering.

Download from GitHub or the foobar2000 Components Repository.
Automatic update from within foobar2000 does not work.

Because it's been a while and the bigger new features will take some work I release this small update.
36
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
Lossy compression(audio/image) is about ignoring some data that is outside of human perception. And for this it is clearly necessary to perform various tricks. So as long as people don't understand, it means there's no problem. It is not as rigid as lossless compression, and we can act more flexibly. However, they are generally not preferred in professional areas and are for everyday use.

The main problem here is that the interpretation of the output can be in many different ways and quite relative. So it is very difficult to come to a definite conclusion in terms of quality.

When we carefully examine the deformations on the image, we can see them with the naked eye. However, it is not easy to analyze changes in the original sound without high-quality audio equipment. At least it's not easy for me.

Since there are higher bit values (24/32) in the audio data, there may also be more noise that needs to be cleared. I can evaluate this issue in later versions. But for now, there are more priority issues. Therefore, a little more time is needed for the lossy option.
37
General - (fb2k) / Re: How to use lyrics with foobar2000
Last post by sveakul -
Several good choices--I have all 3 in a tabbed panel:

1.  Lyric Show Panel 3 (version .6) with foo_multisource 2.1 added

https://www.foobar2000.org/components/view/foo_uie_lyrics3

https://hydrogenaud.io/index.php/topic,90338.msg1037160.html#msg1037160

2.  ESLyric

https://hydrogenaud.io/index.php/topic,122571.0.html

https://github.com/ESLyric/release/releases/tag/0.5.4.1028

3.  Foo_openlyrics

https://www.foobar2000.org/components/view/foo_openlyrics

https://github.com/jacquesh/foo_openlyrics

39
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by [JAZ] -
oh, I forgot to reply to your second question.

No. nspsytune means "Naoki shibata psychoacoustics tuning", and it's one of the tunings of LAME. Although currently I don't remember if they are used in the most recent versions of LAME or not.

Helix is a descendant of the Xing MP3 encoder. As you said, RealNetworks bought Xing, so it also got the encoder.
The changes that have been done to this encoder here in this topic are mostly about preserving and improving the user experience, not about sound quality (other than, maybe fixing bugs due to uninitialized variables or similar).
40
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by cid42 -
There should be intel CPU's late this year with APX at earliest. Doubt it'll be in Zen5, might be in Zen6, designs are done years in advance and intel will have kept it back for competitive advantage. I doubt the gcc support is ready, they have to start adding it in now to make sure it's in good shape by next year.