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
1
Listening Tests / Re: Great killer sample, easy to ABX on most codecs
Last post by shadowking -
OK No hard feelings at at.

I have been running abx tests for the last few days for several hours total. I think I may have a solution of partial one.
I even encoded some tracks to 8bit with dither and the effect was a bit similar to lullaby. Any way I don't know how that fits into
anything but anyhow - I discovered that at around 5 bit per sample or more is needed. Below its like FM radio  - too me not annoying at all but still..   So if one is into 8bit that is the way .  It also translates into 16bit robustness - around 6bps maybe less or more is needed for a lossywav like quality.  Back to codectest16,  I decided on the normal mode since that is the workhorse of WV.  Interestingly, to my ears @576k the modes seem to converge more or less like it don't matter if -x or -h -s etc..  I remember many years ago I read a post by dibrom on regards to MP3 -APS behavior .  He said its a quality 1st approach - reach bitrate first then try to bring it down if safe. So,  Going by that to my ears and test sample set if I take 576 and add some defensive mechanism like -x , smart mid-side stereo and -s , I got down to 500k .  Specifically;  -b500x4s1.  A workhorse setting  'normal' but with big safety net.  Then I guess for completion ; a 'high' setting of -b550x4s1 .  In bps its 5.67 to 6.24 I guess 6 on average.  Anyway now to 320-350k or -b4 ;  use -b4x4s.5 for an alternative. To my ears the difference is not annoying if audible at all in normal volume day to day listening. For middle bitrates I found -s.5 safe so far although you lose a bit of advantage of not getting a full -s1 or even a negative shaping when appropriate though how this actually translates in real life listening is a different matter. I think its a good balance anyway.  For high bitrate above 400,  abx results tell me a -s1 is the way or somewhere from 70-100% upward tilt ( -s.7 to -s1).  I am leaning on -s1 . 
Interestingly, On WV manual -s1 if the default for high sample rates > 48 and hi-res as the noise is 'pushed up into in audible range '.  So it seems to me the -j1 -s1 simple method is also good for very high bitrate 44-48khz- 16 bit.

Anyhow to make short of the long,  Two settings for different goals. Its really simple its almost ridiculous when I write it like:

-b4x4s.5    ~ 352k
-b6x4s1     ~ 530k
2
Opus / Re: xHE-AAC : The Death of OPUS?
Last post by shadowking -
What room for improvement? Just because you think there is any doesn't mean there is, that is called wishful thinking. Also, you can't just fix one "killer sample" in lossy codecs without it having negative consequences somewhere else.

You are correct. Who is doing regression testing ? Not many like that and most don't have time.
3
FLAC / Re: FLAC - stored main chunk length differs from written length
Last post by bennetng -
I have fixed this in WavPack with this commit by rejecting such WAV files.
Thanks. Cool Edit / Audition 24.0 float files use 4 bytes block align and 24 bits per sample in header, will these files be affected? Here are some sample files saved with Audition 1.5:
https://hydrogenaud.io/index.php?action=dlattach;topic=114816.0;attach=22034
[edit]Warning to innocent lurkers: Some of these files are not safe to play outside of Cool Edit / Audition, beware of loud noise!
5
Opus / Re: xHE-AAC : The Death of OPUS?
Last post by shadowking -
> If you want 100% transparency all the time, take a lossless codec

In principle nothing stops something like LossyFLAC or maybe even ("up-tuned") Musepack from guaranteeing 100% transparency due to the way they work. (you can basically require them to maintain a certain SNR at all times, no matter how many bits that would take)

Pure lossless-compressed PCM is always going to use more bits than necessary for louder intervals and that's the lowest hanging fruit to shave off some % of bits.

In addtion to lossyflac, loaded mpc  ,High bitrate WV lossy can be used confidently from around 500kbps . something like -b500x4s1 or more.
6
Opus / Re: xHE-AAC : The Death of OPUS?
Last post by shadowking -
The state of lossy music encoding is disheartening.
Developers are not robots or isolated nerds/geeks. If they can no longer sustain the efforts … pick up the skillsets where they left off and continue investing the same efforts they made. Not make a point of scolding them at every forum opportunity.

The absence of a loud and clear message expressing dissatisfaction with the current state of affairs is often mistaken for satisfaction. "People don't complain, so why bother?" And more often than not, I've seen development resume not because someone decided to dust off abandonware out of boredom, but because they faced the pain and showed empathy for those who reported how this or that change would make life easier or happier. Certainly, there are various ways to report: a hit between the eyes and a sugar-coated plea to name a few. Just as there are original editions of Mark Twain and Agatha Christie novels with words of their era like the N-word and orientals, and there are expurgated editions for a fragile, resentful mindset. For example, a few weeks ago I complained that Helix MP3 encoder, officially abandoned 20 years ago, was not capable of handling more than 16-bit input, and the miracle happened. God bless @Case for that.

Mod edit: Defused potentially offensive word.


Its a catch 22 situation. With Mp3 / AAC it can work due to high user demand.  With less popular codecs like mpc, WV, vorbis
the opposite can happen and already small userbase is further decimated . That may slow down development even more.
7
Support - (fb2k) / Re: Disable tag caching of specific tags on v2
Last post by paregistrase -
As it seems that there is not likely to be a movement in this direction in the near future, I was trying to minimize the impact in memory of excessive quantity and longitude in tags.

First, I get rid of duplicates, like the backup tags created with taggers like foo_discogs. Although some of these tags were big (like release notes, artist profile, etc) the global impact was almost unnoticed. The RAM usage was enormous, to the point that the SMP component crashes randomly without of memory or the entire player get down without even a crash log left behind.

Next step was pointing at the new foo_ID and chroma print tags. Deleting this tags reduce the usage of RAM in more than 50%
With the same number of files first foobar was always at the limit of a 32 app and crashing with every operation that requires a little bit more and without them RAM is about 1 GB,

So until a solution that allow us to unlload this tags or a 64 SMP version that allow us to not be limited by RAM comes out, It is not suitable to use this kind of functionality, at least in my case. With less than 20.000 files tagged with chroma print, I was in a stage when the crashes started to happen even playing a track or loading a playlist.
8
3rd Party Plugins - (fb2k) / Re: foo_vis_spectrum_analyzer
Last post by hormidor -
1) The calculator comes up with colors that don't actually exist in the artwork.
That's a result of the algorithm. To determine the colors in an acceptable amount of time similar colors are put in 'boxes'. Each box can only have one leading color.
2) The calculator selects 9 colors every time, even though, per changelog, "between 2 and 256 colors can be selected".
3) The colours are totally out of order in terms of brightness (which ruins the idea of an amplitude-based gradient).
What do think the settings in the Common / Artwork section are for?

Thanks, I was not aware the settings were in a different section.
9
3rd Party Plugins - (fb2k) / Re: [fb2k v2] SQL Tree (foo_uie_sql_tree)
Last post by chrisdukes -
I think I don't understand the difference between the Batch tab and the Query tab.  ¯\_(ツ)_/¯

Can you refresh if there's only a query in the Batch tab?
Can you only refresh a tree if there's a query?
Does refreshing a tree also recreate a table like executing the query in SQL Console?

If I create TableA in one tree, then I create TableB from Table A in a separate tree, how can I automatically refresh Table A before Table B when I load Foobar2000?  I guess I would want to do the same thing for Refresh All.  I have more tables that are dependent on TableA, but it doesn't matter what order they're refreshed in as long as TableA is refreshed first.

Thanks again for the awesome plug-in!