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
82
3rd Party Plugins - (fb2k) / Re: Biography Discussion
Last post by sveakul -
Thanks for the update!

Can anyone point me to/describe how I would update from 1.4.2 mod 1 to 1.4.2 mod 2 without losing my current settings?

I am running JSplitter 3.6.1.14 with Foobar v2.24.5, 64-bit.  Biography is the only SMP package I have installed.

I appreciate any help you can give.
83
Audio Hardware / Re: Question in-ears magnetic driver
Last post by classicaran88 -
understood then the magnetic force exerted by a large 29" CRT TV does not come close to causing magnetic damage to the dual magnetic dynamic drivers used in In-Ears headphones KZ EDX Pro and KZ EDC Pro

it is something very different from the comparison with 2.5" HDDs that demagnetize more easily
84
FLAC / Re: Multithreading
Last post by cid42 -
Quote from: Porcus on
As I just posted over at https://hydrogenaudio.org/index.php/topic,106129.msg1062688.html#msg1062688 , I ran flaccid against flacout, and it won big time without even digging into apodization functions more than "-8" already does. Limited corpus, since 76 minutes of audio took flacout 44 hours to process.

I gave a "suggestion" in that post:
flaccid as a re-compressor for flac files, where you frame by frame compare source to flaccid and if flaccid cannot improve the frame, then just copy it? (Sure you lose some bits in the frame header by committing to variable block size, but if we really want to nitpick on that, let's just compare the audio part of the final files.)
Doesn't have to take that much development work ... ?

You're suggesting a recompressor that works within the boundaries of the frames in the source? So a 4096 fixed frame could be sliced into arbitrarily small frames or combined with adjacent frames, but if none of that is an improvement just output the (slightly modified) original frame. I mean that could work, but I don't see a whole lot to gain. Unless the source used very strong settings that flaccid isn't, the source frame is unlikely to be smaller. Unless the point is to not recalculate the 4096 frame size at all, which would save a little computation. Flac is a simple enough format that with libflac doing the grunt work you could knock out this sort of thing in a day, converting a fixed frame to a variable frame is a mild pain as you need to redo the frame number and crc's but it's not hard.

flaccid chokes on non-ascii filenames, by that do you mean some windows utf16 nonsense? That wouldn't surprise me. Can't say I've tried utf8 on Linux, that has a better chance of working but it might not.
86
Audio Hardware / Re: Question in-ears magnetic driver
Last post by fooball -
Quote from: classicaran88 on
Are the dual magnetic dynamic drivers of these in-ears very resistant to demagnetization and magnetic losses unlike 2.5" HDDs? To demagnetize or have magnetic losses of these dual magnetic drivers of these in-ear headphones, what power would be necessary? And what power does a 29" CRT have because it has coils and speakers?
What do HDDs have to do with this?  The material in a HDD is DESIGNED to be magnetised and demagnetised, so it is hardly surprising if external magnetic fields are able to erase them.

Why are you asking these pointless questions?  The short answer is you don't need to worry.
89
FLAC / Re: Multithreading
Last post by Porcus -
Ran a few on my full 38 CDs during the week-end to check for "not-outrageously-expensive" improvements over -7/-8 - if nothing else, to get an idea against the Exact Rice build, and on a different computer than my usual. Not rigorously timed.

TL;DR: flaccid beat -8p soundly. The following setting was only a little bit slower, and its 0.22 percent improvement over stock -8 is three times what -8p could show for itself.
--mode gasc --blocksize-limit-lower 2304 --tweak 64 --queue 16 --merge 0 --analysis-comp 6 --output-comp 8

(But, hrmph, flaccid chokes on non-ASCII filenames.)


So, what I ran - presented as kB per extra second to get you what fruits are lower-hanging. Stock 1.5.0 first:
-5 as "baseline": took 6 minutes, 12 032 megabytes.
-7: Took 143 more seconds, 11 974 megabytes. That means -7 did save 407 kB per extra second run, relative to -5.
-8: Relative to -7, it saved 41 kB per extra second run. So here the returns are diminishing quickly already.

Where to go from -8? The above flaccid in "gasc" mode.
15 kB per extra second over reference -8, against -8p's measly 6.


Also tried:
  • @Wombat's "Exact Rice" build. At -8 it saved 0.02 percent over the Xiph build. That did amount to a not-at-all-bad 13 kB per ekstra second. 
  • -8 -A "subdivide_tukey(4)", beefing that one up. About the same as the Exact Rice build, both in time and size (loses narrowly to it due to the classical music). I did not do that setting with the Exact Rice.
  • -8r7, -8pr7 in the Xiph build and the "Exact Rice" build: surprisingly little. Especially surprising especially on the heavier corpus where that fine partitioning is often used - but not so much saved from it. Hardly any difference at classical music. Overall only 3 kB/s saved at -8 (Xiph), and much less at -8p and at Exact Rice.
  • Any synergies between Exact Rice and -p? No. Even less than previous line.  Exact Rice's -8p is slow. 
  • Heavier flaccid: 40 percent more time than the one above, did improve but very little.  --mode peakset --blocksize-list 2304,4608 --analysis-comp 5 --output-comp 8r7  --queue 32 --tweak 32 --merge 0
  • Lighter flaccid: just a little bit faster than the gasc above, and not far worse, was --mode chunk --blocksize-list 2304,4608 --tweak 0 --merge 0 --analysis-comp 8 --output-comp 8r7