January 10, 2017 10:31 PM, "Bruno Pagani via aur-general" <aur-general@archlinux.org> wrote:
Le 08/01/2017 à 19:19, Maxime Gauduin a écrit :
You piqued my interest with bs1770gain, any idea how it fares speed-wise against the default gstreamer backend? I kept using wine + foobar2000 to compute my replaygain values even after transitioning to beets because it's infinitely faster than using gstreamer.
Hi again,
So, after a little bug fix[0], I ran `time beet replaygain -a` (so Album mode, which I expected to be your use case) command on my newly imported (with `-A`and into a new library for this test purpose) incoming folder, which has the following stats: Tracks: 2556 Total time: 1.1 weeks Approximate total size: 102.0 GiB Artists: 150 Albums: 176 Album artists: 56
And here is the output of the `time` command: beet replaygain -a 2775,24s user 32,68s system 80% cpu 58:00,41 total
Note this is on a HDD, which I heard spinning a lot during all the process. So results on a SSD might differ, I could test that this WE if you want, but here we can say roughly 1s per track.
How does it compare to your workflow?
Thanks for doing the testing, I too did some tests on my server over a sample of 373 representative files (flac, m4a, mp3). HDD as well but I only had 15MB/s of disk I/O so it's definitely CPU bound. Here are the results: gstreamer -> roughly 4s per track bs1770gain -> roughly 3s per track bs1770gain is definitely faster, but right now I'm using fb2k over the network where it takes 0.4s per track. Mind you, my desktop has a much more powerful CPU, and fb2k actually uses several threads which afaict beets does not. I'm quite sure I can divide the time it takes on my server by 4 using threads as well which would make beets a viable alternative, I'll look into it when I'm more familiar with ayncio. Also found out about the volumedetect filter of ffmpeg, but I'd need to document myself more about replaygain and its variants to make good use of the output.
Cheers, Bruno
Cheers, -- Maxime