Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rexmadden]

Obviously, this is low priority, but I was trying to use the Analyze Gain feature on the 8.0.265 beta while a song was playing at the same time, and the song I was listening to started to sound funny.  I can recreate the problem.

Rex Madden
rexmadden@yahoo.com

[Matt]

It takes a lot of CPU to analyze replay gain.  It may be too much for your system to try to do that AND play music at the same time.  The best bet is to let it go overnight sometime.

Take care.

-Matt

[cjdshaw]

But playback takes a tiny amount on a decent machine (~2% on my Celeron 900). Replay gain should run slightly slower but there shouldn't be any artifacts. Also, it only occurs when playing an MP3 and analysing an MP3, not while playing an ASX and analysing an MP3. This makes me think it's to do with the two simultaneous decoders rather than CPU usage.

I've reported this bug and had the following response from JimH:
> replay gain issue may have to wait --not sure -- we do notice what you say but....

[KingSparta]

99% on my 700mhz

as a matter of fact you can watch the mem used clim the longer you use it.

[cjdshaw]

mp3 playback taking 99% on a 700MHz CPU? That's really excessive. Even on my 300MHz notebook it's only 15%. Are you sure you haven't got visualisations running or something?

[RemyJ]

I have to agree with cjdshaw.  There's something else going on besides CPU utilization.
As I reported in one of the beta threads, with more than 1 CPU running, the analyze function actually gets corrupted when something is playing at the same time.

I just ran a test...

With my server configured for 1 CPU (a 1.8Ghz XEON), playing an MP3 track causes my CPU utilization to twitch 10-15% at the start of the track and 2-3% every 10-15 seconds or so, but remains literaly 0% throughout the rest of the playback.  If I stop the playback and analyze a track, it spins the CPU at 100% and analyzes at about a 40X rate.  If all threads have the same priority, then it's POSSILE that the playback thread is suffering, but adding CPUs should make the problem get BETTER, not get worse.  

Unless... some common code module is not thread-safe.   In fact, one of the classic symptoms of a non-thread-safe code is that the symptoms get worse as you add parallel CPUs.

To support this theory, I started a track playing, then attempted to convert another MP3 track to a different bitrate.  During the "decoding" phase of the convert, I got the same "skips" but during the encoding phase, which also ran the CPU at 100%, the playback was perfect.  The skips were present in the final converted track!  So, I then enabled the other processesors and attempted to play and convert again and... the decoder phase only decodes the first few seconds of the track and then encodes it into garbage which is the same behaviour as analyze.

So, I think you have a real problem with multiple uses of the MP3 decoder at the same time.

Remy

P.S.  I've never tried to analyze/convert and play the same track at the same time.  I know that's not going to work.

[Gatobrit]

Hi - this issue has been around through all of the v8 betas. I seem to remember that JimH commented a couple of weeks ago that it won't be resolved in v8.

[RemyJ]

Yes, but as I recall that has always been in the context of an annoying playback problem while analyzing replay gain.  The fact that the root problem seems to affect ANY concurrent use of the MP3 decoder and the corruption could happen in either/both streams makes this a much more serious issue.  How many people have been performing mass converts while listening to something else?  Even if they're not hearing the skips in the playback stream, how confident are you that the conversion streams are uncorrupted?

Try this...  Start playback of an MP3 track with good dynamic range, then analyze a soft vocals track and note the resultant radio gain.  Now stop the playback and analyze the same track again (using the cool new feature that let's you do that!) .  If the radio gains were different, then the stream supplied to the analyzer was probably corrupted.

Remy