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
2
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
@Kraeved; I have already mentioned that Player only works with Halac 0.2.7. Also, I did not specify this with an error message. For the next version, I will add this measure to both Decoder and DLL. OK.

Thank you very much for your great suggestions, Case. Such comments are really necessary.
Quote from: Case on
Best option for API would be not to rely on filenames at all.
DLL/SO will not deal with file operations. OK.

Quote from: Case on
And partial decoding is of course very important for realtime playback.
DLL/SE should only take memory address, frame number and data length. OK.

Quote from: Case on
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.
DLL/SO should give us the necessary information such as header(channel count, bit rate...) and metadata. OK.

Quote from: Case on
Oh yeah, and you should specify what calling convention the functions use.
This should be more important especially for Windows. OK.

I will add them in the next version. If I need to repeat, these are the usual problems in the software process and the solution can be produced quickly. However, I need to focus on what I need to focus on (speed, ratio, prediction, entropy ...).
4
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by maikmerten -
@Case thanks a lot for noticing and providing a fix, now pushed onto the dev-branch: https://github.com/maikmerten/hmp3/commit/4e16101b85cdd5171a85facaf3ea9be4327712da

@Replica9000 CTRL+C indeed is baked into the usual operating systems. It sends a signal to the executed program (SIGINT). Programs can choose to react in any way they deem fitting. With the recent changes, hmp3 chooses to stop encoding in a "graceful" manner.

The speed increase on the dev-branch most likely is from now compiling with link time optimizations (-lto flag).

Btw, here's hmp3 encoding my test CD album of choice:

Code: [Select]
real	0m9,585s
user	0m9,436s
sys	0m0,140s

And this is Ubuntu's Lame 3.100 binary decoding the resulting MP3 to WAV:

Code: [Select]
real	0m10,609s
user	0m9,297s
sys	0m1,288s

In real-time, hmp3 is faster *en*coding than Lame is *de*coding ;-)

(Of course, there most likely are faster MP3 decoders, just found this slightly interesting)
5
Support - (fb2k) / Playback ERROR in v2.2 preview 04-26, exclusive mode
Last post by C_g_Z -
In v2.2 preview 2024-04-26, PLAYBACK ERROR when audio is paused or skipped to another track with different sample rate, on an "exclusive mode" output with "smooth seeking" enabled.

Unrecoverable playback error: Output reported latency of 691622877wk 4d 15:24:05.504
6
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by Porcus -
Heard of yes, done no - so what was the output?
Since you claimed for TTA that "There is no ways to do any optimizations here except bruteforce threading", then well, ... timing suggests otherwise, and to the extent that I don't think you need a more fine-tuned setup.

Nor do I think that would have tipped over as big differences as the following:
 * WavPack verifies three times as fast as Monkey's - and 10x as fast as reference FLAC (because it doesn't do fast-verify) and 28.6x as fast as ffmpeg-generated WavPack 4 files (since those files don't offer the option)
 * Different FLAC builds differ in encoding time by a factor of 2.5 on -5, and even more at -8: https://hydrogenaud.io/index.php/topic,123025.msg1029768.html#msg1029768 .  Sure one could be interested in an explanation, but you don't need that level of detail to point out that there are big differences.
 * ffmpeg -threads 1 decodes nearly twice as fast as reference flac at -5, but several times slower at low block sizes
 * ffmpeg outright rejects FLAC files instead of decoding.  Heck I even got it to reject subset FLAC.  And when it has encoded .wv files it cannot decode itself, then seriously: When flaws are like that, who would whine over the timing tool?!
9
MP3 - Tech / Did Lame 3.99 cause CBR degradation?
Last post by fred-hy -
I prefer Lame 3.98.4 over later versions as I find that it introduces less artifacting to my ears at 128kbps CBR (Haven't ABX'd though)

I've recently looked through the Lame changelogs and it says that version 3.99 made all modes use the same psychoacoustic algo as VBR New, due to one user's sample that sounded garbled in CBR and -q3.

Has anyone done an ABX to confirm that the sound quality is any different?