Thanks, but I've got thousands of folders without a consistent structure, so parsing strings would be laborious.You could do it with foo_sqlite, but if you're just doing one album at a time it's probably just as easy to do it with Masstagger scripts and keyboard shortcuts e.g. one script to set discnumber to 1 (Ctrl+1), one to set discnumber to 2 (Ctrl+2) e.t.c., and do it from the playlist window.
Also, I'm wanting to edit the album tags as I go (to removed 'CD 1'-type suffixes and make the album tags identical, so manual tagging would be quicker than parsing.
Really, I'd want something that works in a similar way to the 'Auto track number' function, but for Discnumbers.
I don't use the Properties panel for editing but given there's an 'Auto track number' I'm surprised there's not an equivalent for discnumber.
I think i have the same problem, my cpu is zen2 4650g(6c12t), i got around 280~300x under command line @ single thread with autodidact's clang build or rarewares' gcc build, I also compiled helix myself with clang plus linktime optimization, my version got around 480x. maybe that's the key.To be honest since i did read this i thought you have the same problem as @KevinB52379.
here's the binary, you can try it.
I don't see anyone replying to your original wondering about the need for --noreplaygain. That command line parameter is there to make the encoding faster by preventing lame from computing a track gain for the file. If you don't care about ReplayGain, calculating the gain values is a waste of processing power. If you do care about ReplayGain, calculating only the track based values is most likely a waste of time. It's better to let foobar2000 calculate both track and album based values once encoding is done. And not only is foobar2000's scanner more optimized and faster, it also offers several advanced options people may like.
The -S is there also for performance reasons. It tells the encoder it doesn't need to waste any cycles printing progress/histograms to the non-existing console screen that no one can even see.
-S --noreplaygain -b 128 - %dis the "-b 128" right?
System hang. The file progress bar increases, but the files being encoded with foobar2000 never changes, and I never see the elapsed time, estimated time, encoding speed, and the 'pause" and "abort" buttons never appear.You keep describing what the problem looks like in Foobar2000 and ignore the suggestion to test Helix MP3 encoder in the terminal. Start encoding one relatively large WAV file (e.g. merge songs from the same album into one WAV file) and describe what you see. The encoder outputs its own status report with various counters.
I've managed to compile the binary using visual studio 2022, it runs quite slow at my env(about 1/3 speed compared to clang version), but you can test if it will hang your system @KevinB52379 .
System hang. The file progress bar increases, but the files being encoded with foobar2000 never changes, and I never see the elapsed time, estimated time, encoding speed, and the 'pause" and "abort" buttons never appear.You keep describing what the problem looks like in Foobar2000 and ignore the suggestion to test Helix MP3 encoder in the terminal. Start encoding one relatively large WAV file (e.g. merge songs from the same album into one WAV file) and describe what you see. The encoder outputs its own status report with various counters.
I've managed to compile the binary using visual studio 2022, it runs quite slow at my env
(about 1/3 speed compared to clang version), but you can test if it will hang your system
Command Mean [s] Relative
------------------ ---------------- -------------
hmp3chang.exe 4.890 ± 0.021 1.00
hmp3chang_vc.exe 10.558 ± 0.041 2.16 ± 0.01
Good to know. There are no longer many options that can cause the issue you are facing. I think antivirus or other security product that scans or sandboxes executables is the only thing that can do this.
The converter in foobar2000 uses very low priority by default and you said you haven't increased it. These encoders don't touch priorities so they do their tasks with leftover cycles. Memory consumption is no different between compiles.
You must have some high priority process(es) running on the same core as the UI processes and steal all the processing power from the UI operations. Or a sandbox goes haywire and consumes all the system memory. Swapping will make machine slow even with SSD.