Skip to main content
Topic: foobar2000 v1.4.1 beta 3+4 replay gain scanning (Read 805 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar2000 v1.4.1 beta 3+4 replay gain scanning

Something change with replay gain scanning?

My scan speeds dropped considerably in the new betas - from around 150x down to currently 25x.

No other system changes and FB is the only running process.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #1
No changes AFAIK. File buffering might be changed. Speeds seem identical between the latest beta and 1.4 at least for albums that get cached in memory. Testing cold scan speeds would require rebooting to flush memory.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #2
for sure something is screwed up.

Scanning 5 albums with the betas:


rescan same 5 albums after reinstalling 1.4 over the betas:


no other changes between tests. btw if FB is in bkgd during scan, speed drop to nearly 1X! in beta
(win10 64bit)

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #3
For me speed is about the same.
Do you use oversampling or downsampling?

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #4
replaygain speed drastically changed with fb 1.4 already - in the end i blamed wine for it.

p.s.: i also have some trouble with my database (updated my portable installation):

there exists a lot of duplicates when searching for a title. removing duplicates helps, but it is still kind of annoying.

also, some tags changed without my intervention. i have set up some autoplaylists and wondered about missing titles. in the end, i checked the corresponding tags and noticed that the notation changed: Jazz turned to jazz?

i am curious to know if this all is wine related?

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #5
If you replaygain scan albums you have just replaygain scanned and you are not low on memory, the files will be in Windows' cache and you have just eliminated all disk access delays. If the data is on a regular mechanical hard drive fragmentation for example can slow things down terribly.

I just tested ReplayGaining a test album in 1.3.20, 1.4 and 1.4.1 beta 4 and 1.3.20 was the slowest. 1.4 and 1.4.1 beta had the same speed. This was not tested after careful rebooting though so the results are for cached material.

One thing that could slow down 1.4 and newer versions is the on-by-default downsampling for hi-resolution audio. But that's at least not the case for mjm716 since mp3s don't support that.

Also if you use True Peak scanning picking a slow resampler will certainly affect things. Use SoX or PPHS normal quality for fastest results.

I think tag troubles are quite off-topic in this thread. But I'm quite positive Peter hasn't changed how "jazz" is displayed in the formats that use hard-coded lists for common genres.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #6
I'm quite positive Peter hasn't changed how "jazz" is displayed in the formats that use hard-coded lists for common genres.
to be precise, it is a custom tag PLAYLIST that got affected, not the common genre tag. now back ontopic ;)

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #7
I now performed the scanning speed test with reboots between the sessions. 1.3.20 RG scanned the test album at 739.60x realtime speed, 1.4 at 723.57x speed and 1.4.1b4 at 735.46x speed. Once the album is cached the scan speed is a bit over 3000x realtime speed with all the versions. These speeds are so close to each other that I'd say any differences are caused by random background activity.

If you do find a scenario where the new version indeed is slower, please post details.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #8
Check MP3 decoding speed, as that's apparently what format they're using? Also check that some other decoder hasn't taken priority over MP3 files.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #9
replay gain settings exactly the same in both tests

btw wish I had a system like yours Case, would be nice not to have to nitpick performance issues. ;)
However maybe slower systems are part of the problem?


Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #10
Peter checked the logs and there have been no ReplayGain or file access related changes from beta 2 to beta 4.

I tested MP3 scanning and I get identical speed on 1.3.20, 1.4 and 1.4.1 beta 4. CPU shouldn't affect that and yours is new enough to include all the same instructions as mine.

Have you redone the test between versions in identical conditions? Either test all versions a couple of times so the files are cached or test the versions after system reboot so the files aren't cached in any test.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #11
OK, I'm a fan of a scientific method, so to humor us both I installed 1317 / 14 / 141b4.
New portable installs, using the same set of MP3 files - any existing RG data cleared before each test.

RG setting was: Quiet Mode on / Downsample on auto / True Peak auto 2x (for 1317 2x was manually selected)

Each test performed after new restart.


1317:


14:


141b4


speeds did not vary significantly during scantime - they were the same at scan start as termination


Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #12
Strange, but: I performed a clean fb2k install of beta 4 this week-end. [Which resolved some - to me - unexplainable issue with a component - Case has the details].

And suddenly yesterday night I saw four-figure numbers for RG scanning.  And come to think of it, I have seen that before ... but not in a while.
Memento: this is Hydrogenaudio. Do not assume good faith.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #13
That was enough details to find a problem. True peak scanning with PPHS resampler has gotten dramatically slower. Assumedly from the "PPHS resampler bug fixes (inaccurate reported latency, crashing with extreme sample rates)." changes.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #14
Thanks, but your response creates more confusion.

If the process is so much slower now, does that imply my previous library RG data is inaccurate?

For general MP3 RG scanning, is True Peak Scanning not required?

If it is required, I was using auto 2x, while PPHS is a different option.
Where can I find more detail about these options?




Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #15
It's a problem with the fixes. They were not supposed to slow the resampler down. Accuracy isn't affected.

True Peak scanning is not a requirement. Knowing the intersample peaks only allow protecting against clipping that could happen after resampling or in DAC. If you use ReplayGain without using extra loudness boosts you most likely won't run into clipping anyway.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #16
Thanks for the info - for such a major change, it would certainly be nice to find details in the version update info.

btw, with True Peak Scan off, I'm getting a much more respectable ~600x scan

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #17
Thanks for reporting.
Turns out that recent fixes for downsampling of extreme sample rates ("DSD1024") backfired and caused performance loss with sane configurations.
The next update will restore proper performance of PPHS resampler.

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #18
Good news about the fix in the next version, thanks Peter :)

My results:
foobar 1.3.20, replay gain, single album (m4a): 2785,16x
foobar 1.4.1b4 replay gain, single album (m4a): 1680,53x

Re: foobar2000 v1.4.1 beta 3+4 replay gain scanning

Reply #19
setting is saved but radio button doesn't look right after hit reset button

 
SimplePortal 1.0.0 RC1 © 2008-2018