INTERACT FORUM
More => Old Versions => Media Center 14 (Development Ended) => Topic started by: leezer3 on July 27, 2009, 10:57:40 am
-
The issue with certain MP3s I reported in the last two posts of the .138 build thread appears to still be present.
Any chance of a developer comment on this- It's proving a major pain in the rear (I've currently found 6 albums with this issue, everything plays just fine, just kills the analysis process which means I have to keep a constant eye on it) :)
-Leezer-
-
Where did the files come from? Did you rip or convert them?
-
They are all tape rips, although not mine.
The MP3Utility error is this:
Processing: I:\Audio\Mercedes Lackey\MS02- Storm Rising\Mercedes Lackey-Storm Rising 13 of 71.mp3
Warning: Sync error reading frame header 23,105 expected at byte 2,416,181. Approx. time: 10:06 (100.0% through audio).
Previous valid frame header located at byte 2,416,077.
Resync failed (reached end of file).
Summary: 23,104 total frames processed (11,316 padded, 11,788 unpadded). Bitrate is constant.
Basically, looks like something's been truncated somewhere, although they verify with the MD5 hash I have.
Edit:
Sample file (The one analysed above)-
http://rapidshare.com/files/259537640/Mercedes_Lackey-Storm_Rising_13_of_71.rar
Logs are currently in the last two posts of the build 138 thread, and I can transpose them or attach if necessary, but they're very large :)
-Leezer-
-
We've seen an unusual number of file problem in the last several months. There are two possibilities that I can think of. One is that there is a bad utility around that is mangling the files. The other is that content owners are seeding file sharing sites with broken files.
So that's why I'm asking ... Where did you get the files? What software was used to create them (if you know)?
-
Any chance of a developer comment on this
I haven't been able to reproduce the problem.
I've run the file you provided through the analyzer many times and it's always worked. Anything else we need to do to get it to tank?
Thanks.
-
Jim- These came from Demonoid. I know the uploader, and trust that what they're putting up isn't fake or damaged. Additionally, this isn't commercially available stuff- That I don't torrent :)
Ripping wise, these came from a custom tape player to a line in jack. Encoding I believe was done with Goldwave, although I'd have to chase that.
Matt-
I'm currently running with 4 concurrent files. For the example file I add the whole album (71 files) and set it running. It may finish one or two files before everything falls over, this seems random. I can reproduce this in both MC14 & MC13.
The attached log is from MC13, just in case it shows anything different to the others
-Leezer-
-
Headbash time then ;D
This is a second example of the same issue-
http://rapidshare.com/files/260657311/Mercedes_Lackey-Storm_Rising_71_of_71.rar
I can add 25 copies of this one to audio analyse, and it'll crash reliably within the first two or three.
-Leezer-
-
We were able to reproduce it.
The problem is that those are mono files and it's causing a buffer overflow.
It'll be fixed next build. Thanks for the help.
-
great news!
Thanks Leezer for chasing this down. I've been seeing strange analyze crashes for quite a while.
-
Jim referred me to this thread. I've been having a persistent obnoxious problem with MC 13.0.172 (and prior) that might be related to this problem in MC 14.
Here's my latest post on it: http://yabb.jriver.com/interact/index.php?topic=52987.msg362441#msg362441
Guessing that the particular section of playback is the same in MC14, once solved I hope the fix can be back-ported to MC13 (I own an MC14 license but am waiting for a bit more stability before moving my 80K+ audio tracks into it.)
Briefly, the problem is total audio dropout in the playing track just where the next track starts using "cross fade aggressive". In this mode, for a second or two the current and next track's audio overlap. With SOME files there is an audio dropout right where the next track begins, accompanied by MC rapidly flashing "buffering". The problem is totally repeatable, and happens on multiple PCs. However, it only happens to some tracks; the vast majority have no problem.
All the tracks are MP3, ripped at various times over several years, so different rip tools/encoders/bitrates/specs. Some are CBR, some are VBR. Most are 2-channel stereo or mono sound, but some mono audio are 1-channel tracks.
However, while some of the problem tracks are 1-channel audio, not all are. But 1-channel is usually the case. But#2: the problem doesn't happen with all 1-channel tracks.
If the tracks are not played in overlapping mode the dropout doesn't happen, or maybe it does but there's no way to notice it. But "cross fade aggressive" for "1 second" is my favorite "sound" from MC -- I can't give it up. I like this sound so much I use a laptop in a vehicle to run MC while driving (hands off, of course).
I've run some of the "problem" tracks through MP3Utility but no problems are reported. So the dropout/buffering seems to be something that trips up MC at the transition of certain files. Since MC always rapidly flashes "buffering" during the audio dropout, this might help isolate the section of code to inspect.
Also, it would be helpful to know what "buffering" means during playback, since it is being displayed to the user as worth knowing. The problem is not improved by MC's "prebuffering" setting, which I bumped up to 10 seconds, but I don't know what "prebuffering" means either (my guess is it is related to file loading from disc...).
-
For what it's worth, the analyse crashes I was seeing are fixed in the current build :)
Crossfade isn't something I use, so I can't commend on that, but try the current build with a copy of your library and see whether that fixes things.
No comment on backporting, Matt or JimH would have to answer that.
-Leezer-
-
I own an MC14 license but am waiting for a bit more stability before moving my 80K+ audio tracks into it.
I am a very cautious guy with a big library and I made the switch to MC 14.0.45 a couple days ago. I have done a lot of testing and MC 14 appears to be at least if not more stable than MC 13. Don't think you have anything to worry about.