INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: MP3 Decoder Concurrency and Corruption (was Analyze Gain)  (Read 2754 times)

RemyJ

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1245
MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« on: May 09, 2002, 07:31:05 pm »

I started a new thread for this problem because it's grown from "skips during replay gain analysis" to any concurrent use of the mp3 decoder, and it's no longer cosmetic.

To recap... Anytime 2 tasks that use the mp3 decoder run at the same time, either or both of the mp3 data streams get corrupted.  For example, play an mp3 track AND do one of the following:
  analyze replay gain on an mp3 track OR
  run the converter on an mp3 track OR
  burn an mp3 track to audio CD

Many people have reported skips in the playback while those other tasks are running and the perfectly plausable explanation has been that those other tasks are CPU intensive.  EXCEPT...

1.  I've checked the results of those other tasks executed while playback is running and found that there are skips in THEIR results or that radio gain results are NOT the same as when a track is analyzed with nothing else playing.  I've created more than a few coasters without even realizing it and had to go back and re-analyze radio gain on many tracks.

2.  I've run other apps that max cpu usage without any effect on playback and if I try to convert while maxing cpu with another app, the only effect is that the convert runs slower but it's never corrupted.  

3.  On a multi-processor system, the result is worse and almost amusing.  If I start a playlist of 100 tracks playing, then try to analyze replay gain on a different 100 tracks, the player jerks and skips through the playlist while the replay gain analyzation jerks and skips through its list with the audio playing tiny fragments of tracks in BOTH lists.  It's like someone is running the car radio up and down the AM dial.  Actually, I probably never would have investigated further and found the corruption if I hadn't had these problems on my multi-processor server.

So...

Are other's seeing these results? (beyond just the skipping in playback)

Does anyone see the same results with other other decoders?  APE appeared OK but I didn't test the others.

Opinions as to the severity of the problem?  In my mind, this would be a "show-stopper" to a production release because of corruption that might not be readily apparent.

Remy

------------------
Media Jukebox PLUS 8.0.270

CPU: Intel Pentium 4 1781 MHz MMX  (*** actually dual 1.8Ghz XEON ***)
Memory: Total - 523 MB, Free - 382 MB
OS: Microsoft Windows 2000  Server 5.0 Service Pack 2 (Build 2195)

Internet Explorer: 5.00.3315.1000
ComCtl32.dll: 5.00.3103.1000
Shlwapi.dll: 5.00.3502.4373
Shell32.dll: 5.00.3315.2902
wnaspi32.dll: 4.70 , ASPI for Win32 (95/NT) DLL, Copyright © 1989-2001 Adaptec, Inc.
Aspi32.sys: 4.7
Logged
Fedora 38 x86_64 Xfce

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42028
  • Shoes gone again!
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #1 on: May 10, 2002, 06:44:30 am »

Thanks for all the details.  

Looking at the old code, it's a wonder it worked at all with two mp3 decoders running.

However, everything should be all better next build.

Thanks again for your help.

Take care.

-Matt

(p.s. sorry to anyone who's reported this in the past and got a "maybe your CPU can't handle it" response Next Page )
Logged
Matt Ashland, JRiver Media Center

ZRocker

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1257
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #2 on: May 10, 2002, 08:02:35 am »

Matt,

That's great news!!

I was going to chime-in last night (but didn't), but I use MP3Gain to Replay Gain analyze complete albums of MP3s all the time with MJ playing MP3s and never experience MP3 playback problems...MP3Gain just analyzes quietly in the background.  And, I'm on a really slow system by today's standards (PII 450 w/256meg ram...it just keeps on working smoothly).
Logged

cjdshaw

  • Guest
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #3 on: May 10, 2002, 09:23:07 am »

Hooray. Thanks Matt. As far as I'm concerned, MJ is now bug free. That was the last niggling one left over. I'll toast you guys with an extra drink tonight.
Logged

shdbcamping

  • Guest
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #4 on: May 11, 2002, 12:03:04 am »

this may sound crazy, but most encoding/decoding programs that i know of need to have dedicated existence during use... meaning that you give the program a task and then let them do it. you can try playing or whatever else while a program like MJ is "borrowing" it, but if you want the program to do something else, open it and run that process outside MJ. It works better and have done it with several of the MJ plugins that i've found and have as separate program files. Playing is a lot more demanding than one would like to give it credit. If MJ has it, i've found it for free. MJ is just a great place to get singular functionality in an almost completely convenient package. Try the second attempt with the program running a second time.
hope this helps
Sean
Logged

hyslopc

  • Guest
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #5 on: May 11, 2002, 02:10:25 am »

Wow - reading this topic led me to search these forums and google, to finally discover that MJ supports something called "Replay Gain".  Then I read the MJ8 help, which incorrectly says that you turn this on from File|Tools.  Then I browsed around MJ8 until finally finding it in the "DSP Studio".  Now I've clicked it - I guess that's it?

I think this is such an incredibly common thing to want to do - shouldn't it either be turned on by default, or made much, much easier to find?  I think it should probably be in Settings|Options|Playback settings.
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42028
  • Shoes gone again!
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #6 on: May 11, 2002, 07:12:25 am »

hyslopc,

We're one of the first major players to embrace Replay Gain, and we weren't sure if anybody would use it.  So, we buried it a little.

We'll try to play it by ear, and if a lot of people use and enjoy it, we'll make it slicker and more "to the front" in MJ 9.

Take care.

-Matt
Logged
Matt Ashland, JRiver Media Center

sekim

  • Guest
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #7 on: May 11, 2002, 07:24:09 am »

Matt,

Does this mean there is the possibility of having an RGA button added to the toolbar in the next version of MJ? The more I use RGA the more I like it. But, jumping through the hoops to get to it kind of sucks.
Logged

cjdshaw

  • Guest
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #8 on: May 11, 2002, 08:01:22 am »

Matt:

Or having it done automatically during/after CD ripping and encoding?

hyslopc:

Turning on RG under DSP studio tells Media Jukebox to adjust the volume according to stored values. You also have to generate these values by opening File Properties on your files, then doing Tools->Analyse Replay Gain
Logged

RemyJ

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1245
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #9 on: May 11, 2002, 09:06:11 am »

>>> this may sound crazy, but most encoding/decoding programs that i know of need to have dedicated existence during use...

Yeah, but that's a limitation of those programs (or programmers) Next Page.  It doesn't take much to design software to take advantage of multi-threading and the MJ MP3 decoder is implemented in a DLL which lends itself very nicely to being shared by multiple threads of a single process.  I believe it was the MJ development teams's intention to allow multiple use of the MP3 decoder, the implementation just has a few bugs.  That's not surprising; i've written tons of multi-threaded code and it only takes 1 static integer variable to screw it up and usually a few days to find it.  Usually it's a junior programmer who wanders by your desk, look over your shoulder at a chunk of code you've been pulling your hair out over and says "shouldn't that index variable be local instead of static?".  But I digress...

>>> Playing is a lot more demanding than one would like to give it credit
True, but considering you can get a 1Ghz PC for under $900 these days demand shouldn't be a design issue.  On my 366Mhz laptop, normal playback takes < 15% CPU and on my 1.8Ghz server, the CPU meter just barely twitches.  On the other hand, on my 133Mhz lap/doorstop, CPU is just about maxed.   The software should be designed to allow multiple concurrent uses even if for some it might not be possible due to hardware limitations.  

>>>Try the second attempt with the program running a second time
You can't have more than 1 instance of MJ running at the same time (at least I haven't found a way).

Remy
Logged
Fedora 38 x86_64 Xfce

RemyJ

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1245
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #10 on: May 11, 2002, 09:11:36 am »

>>> Matt: "However, everything should be all better next build."

Well, If I haven't said this before I'll say it now:  You guys are great to work with!  I can't think of another development team as interactive and responsive as yours (including unfortunately, my own!!)

Remy
Logged
Fedora 38 x86_64 Xfce

hyslopc

  • Guest
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #11 on: May 12, 2002, 12:09:56 pm »

cjdshaw - thanks for the tip.  I was wondering why it wasn't working!  So, of course I want to analyze all of my files - I am guessing that I should select them all, choose properties, then File|Tools|Analyze, etc?  I know it will take a long time, but that's OK.  Just want to make sure that I'm on the right track here.  Any more info about Replay Gain?  I've read the "Replay Gain website", but one thing's unclear to me - what is the "gain level"?  The default is 0db - what does this mean exactly?  Also I assume that this is the playback level, and that the analysis is independent of this setting?
Logged

cjdshaw

  • Guest
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #12 on: May 12, 2002, 02:18:12 pm »

Correct. It acts like a pre-amp so you can adjust the playback level of all your tracks. |PLS|6dB seems about right for me and I know other people use it. Just make sure you aren't seeing a peak level above about 90% in DSP Studio.

You are on the right track about analysing. Make sure MJ isn't playing at the time though, as there's a bug in this build which corrupts playback and analysis if they're going at the same time.
Logged

JimH

  • Citizen of the Universe
  • *****
  • Posts: 7604
  • Miller drives a tall-masted tractor on the ocean
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #13 on: May 13, 2002, 11:56:37 am »

The MP3 decoder bug from the beginning of this thread should now be fixed in 8.0.272.

It does not affect version 7.x users since playback while another thread was decoding was not allowed.
Logged
Jim Hillegass
JRiver Media Center / Media Jukebox

RemyJ

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1245
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #14 on: May 13, 2002, 12:19:04 pm »

>>> The MP3 decoder bug from the beginning of this thread should now be fixed in 8.0.272.

Well, for the processorily challenged it is Next Page

Those of us with multiple CPUs still get corruption in both streams.  As I reported in the beta thread however, since it now works fine in single cpu mode, I can force MJ to use only a single cpu and process 2 streams with no corruption and no real loss of performance.

thanks...Remy
Logged
Fedora 38 x86_64 Xfce

hyslopc

  • Guest
RE:MP3 Decoder Concurrency and Corruption (was Analyze Gain)
« Reply #15 on: May 14, 2002, 02:45:42 am »

Multiple CPUs are the ultimate test for any multi-threading code.  If you want to test your threading code to make sure it is really bulletproof, run it on a dual-CPU PC.  Every development team should have one dualie for testing purposes.
Logged
Pages: [1]   Go Up