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
21
3rd Party Plugins - (fb2k) / Re: Charts & Stats
Last post by regor -
Btw, the most obvious error is stats are doubled in most cases. So instead of 56 listens, it counts 112. (not saying that's the only error, since I did not check it thoroughly)

This is for tracks/albums which are unique on my library, so no multiple copies and other situations not handled by design.
24
3rd Party Plugins - (fb2k) / Re: Charts & Stats (using Statistics framework)
Last post by regor -
Ok, so this is how it looks for now:


Needs foo_enhanced_playcount or foo_playcount_2003. (only one of them)

Currently set to display 2025 stats. Some global stats still missing.  JSplitter / SMP package.

Note listening history is only available since those components were first installed; but the charts may be tweaked, anyone missing such data could change the charts to display raw playcounts, rating or whatever available.

To switch time ranges, not only the 'Time range' setting must be changed but also the 'Data filtering' query; the latter it's set to only use tracks played at 2025 by default. While it's not strictly needed to use a query filter, it speeds up calcs, since it directly discards a big portion of your library.

Note some settings affect the entire panel (like the data source or filters, background, etc.), while others affect only the focused chart. It should be intuitive enough.

It's a bit raw, but should work fine. Stats should be 100% accurate (since they work on my other packages), other parts not sure ::) I reused everything from Timeline-SMP and disabled some menu entries related to 3-d graphs, if you spot something which seems to be "useless" let me know. Maybe I missed something.

Right now there is no scrollbar support, so adjust size to your liking. Also data calculations will be improved, since it's currently async but done in parallel, which is not desirable for UI responsiveness. More will come later, since this was just joining the puzzle and did not really add a lot of new code.
25
Off-Topic / Re: EAC - a efficient audio codec for very laggy networks
Last post by MihaiPopa12346 -
Quote from: Porcus on
Maybe I'm old and grumpy (<insert joke about what this forum actually has seen on April 1st and so ...>), but with all due respect ... what is this even?

* A specification with no specification, no less any proof of concept
* Claims of "high-quality stereo [...]  at just ~8 kbps and very high quality at ~12 kbps" - with no justification whatsoever and no indication on how it is even supposed to be achieved, and even less within the unspecified specification. And "archival" stereo quality from 22 kbit/s.
* And a claimed comparison with "WAY better quality than", again unsubstantiated
* Atmos, and with no information on whether it is supposed to be royalty-free ... I (IANAL) suppose it is royalty-free as long as it doesn't exist, but are you calling on people to code it at their risk?

To cap it all, an abbreviation that would only cause confusion, especially here where you post it - if it ever were to come about.

To clarify, if they made a encoder and I encode to Ultra-High quality setting or the likes, that is true. But at the default setting, this should be similar quality at up to 33 to 50% increase in bitrate but lower than xHE-AAC.
But that makes a great April Fools joke! :D :D :D
If someone releases a encoder called "vHE-AAE" (very High Efficiency Advanced Audio Encoder), which the default setting should be the maximum quality and @Kamedo2 makes "Personal blind sound quality comparison of xHE-AAC, vHE-AAC, and Opus", and says that vHE-AAC beats xHE-AAC and Opus, I will die of laughter and switch to vHE-AAC immediately! :D :D :D :D :D

Edit: Removed unneeded blank lines and add about making a blind test. Also added emoji. Some more cleanups. Added some more information and a typo fix.
27
MP3 - General / Re: LAME and GPSYCHO
Last post by shadowking -
Quote from: KevinB52379 on
@shadowking  - I'm just curious, is there a particular version of LAME you recommend overall for this?  I'm asking because I've read that LAME 3.98.4 is good, and so is 3.99.5, but I've read that 3.100 has regresstion in audio quality on these forums after some research?  What about 3.101b3?  Thanks! :)

I use 3.100.1  3.99.5 is identical to 3.100 in quality.  3.98.4 also has the flaws.

I would try --abr 175 -q4 or -q7 with the current version to see if you prefer that or 3.93.1
29
Off-Topic / Re: EAC - a efficient audio codec for very laggy networks
Last post by Porcus -
Maybe I'm old and grumpy (<insert joke about what this forum actually has seen on April 1st and so ...>), but with all due respect ... what is this even?

* A specification with no specification, no less any proof of concept
* Claims of "high-quality stereo [...]  at just ~8 kbps and very high quality at ~12 kbps" - with no justification whatsoever and no indication on how it is even supposed to be achieved, and even less within the unspecified specification. And "archival" stereo quality from 22 kbit/s.
* And a claimed comparison with "WAY better quality than", again unsubstantiated
* Atmos, and with no information on whether it is supposed to be royalty-free ... I (IANAL) suppose it is royalty-free as long as it doesn't exist, but are you calling on people to code it at their risk?

To cap it all, an abbreviation that would only cause confusion, especially here where you post it - if it ever were to come about.


30
General - (fb2k) / Re: Free Encoder Pack
Last post by Case -
The Apple's dlls do depend on Microsoft Visual C runtimes, but those extra files you mentioned are not needed. They are something else than normal runtimes as they all have "_app" at the end of their names.

Currently CoreFoundation.dll and some other dlls for example depend on vcruntime140.dll, so I wanted to copy these over in case they aren't installed system wide for the user. But I didn't want to hardcode the currently used runtime dll names as any update from Apple could make it depend on more runtime DLLs, or even differently named dlls if they changed compiler. So I tried to be future-proof by making it copy the standard C runtime components with wildcards, like vcruntime*.dll.

Apparently this backfired, though only harm is that it uses extra space. You can safely remove the extra files. I'll fix this for the next update, thanks for pointing out.