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
71
General - (fb2k) / Re: Foobar2000 controller for Android 14
Last post by regor -
One question, when you say "It's not compatible", you mean google play doesn't let you install it? Or what?

Is not possible to just install the apk within Android if you download it from other place?

EDIT: for some reason, I have tried to look for the app at google play and Aurora store and now it's gone (?). I'm sharing the original files at the http control thread.
74
General Audio / Re: Cutoff frequencies of lossy codecs
Last post by DVDdoug -
I don't know much about low bitrate encoding.    I suspect the LAME developers don't care much about it.    From what I can tell, they are more interested in getting transparent, or near-transparent compression, possibly at the lowest bitrate that's possible.   

Quote
Why those modern encoders are giving higher and higher cutoff points every day?
Maybe because a lot of people judge quality by looking at the spectrum rather by listening?  Of course that's not what we do here.

Quote
I started to see that most lossy encoders are starting to give higher and higher cutoff frequencies for a given bitrate (for example, FhG vs Lame). This may sound attractive, but a higher cutoff frequency means more black space in the frequency area and this sounds
With lossy compression some data must be thrown-away.   There are trade-offs.   If you force it to keep the highest frequencies something else will be thrown away, and what gets thrown-away may be more important than the high frequencies.    Once you are hearing compression artifacts different people may prefer different tradeoffs.    At higher quality settings, I assume the default LAME settings are optimized for most listeners and most program material    OGG or AAC may be able to do better, but I'm pretty sure LAME has been pushed as far as it can go.

Also at higher quality settings, it you hear an artifact it's usually not the loss of high frequencies you hear.   It's usually something else.    The highest audio frequencies (near 20kHz) are weak in normal program material so even if you can hear to 20kHz with loud test-tones in a hearing test, they are usually masked (drowned out) by not-as-high frequencies.     Eliminating "drowned out" sounds is the main way lossy compression gets-away with throwing-away data. 

You are limited to half the sample rate (Nyquist) so at a sample rate of 11,025 the audio can't go above 5512Hz (even with lossless compression or no compression.)
75
General Audio / Re: Cutoff frequencies of lossy codecs
Last post by john33 -
Quote
This may sound attractive, but a higher cutoff frequency means more black space in the frequency area and this sounds horrible to me. (An ABX is not needed per TOS because this is not about quality, this is about "sound color".) For example, a FhG MP3Enc lowest quality encoded 16kbps 11025Hz mono MP3 is pretty good for me,
I don't mean to sound rude, but you have a strange idea of what constitutes 'sound color' and an even more strange sense of what constitutes 'good sound'! It must be clear by now that you are in a minority of one. Ultra low bitrate/samplerate does NOT generate anything that sounds good by any metric, certainly not in mp3.
80
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by maikmerten -
One thing I've been pondering for a future release is improving hmp3's ability to serve as a web-radio encoder. MP3 still is very much in use there for maximum compatibility. Also, it seems most radios use CBR (meh) - and CBR is pretty robust in Helix.

Currently, hmp3 buffers quite a lot of data before flushing output to file or stdout: The encoding application will wait for ~126 KB before triggering a flush (variable "bs_trigger" in tomp3.cpp). For 128 kpbs streams, that's about 10 seconds of delay, for low-bitrate streams like 32 kbps (for that authentic dialup multimedia experience), that's about 40 seconds of delay.

For web radio, I guess it's best to flush encoded frames directly. This is trivial to fix, and I consider flushing packets directly if the output is stdout...

@Case Any opinions if "always quick flush to stdout" makes sense - or should this be behind a switch ("-QF" for quick flush or "-LD" for low delay....)

Flushing every packet (to stdout, to file can be another story) doesn't seem to impact performance significantly, so I wonder if a switch makes any sense at all here.

Code: [Select]
time hmp3 test.wav - > test.mp3

(Duration of test.wav: 01:15:01.00)


Flush on every packet:

real 0m8,593s
user 0m8,467s
sys 0m0,108s

real 0m8,591s
user 0m8,445s
sys 0m0,138s

real 0m8,615s
user 0m8,448s
sys 0m0,128s


Flush every ~126 KB:

real 0m8,594s
user 0m8,515s
sys 0m0,072s

real 0m8,666s
user 0m8,565s
sys 0m0,092s

real 0m8,571s
user 0m8,457s
sys 0m0,112s