MP3 Compare

[chrroe]

I took a brief look at the new MP3 Compare in build 445.
But first of all I must confess that even under BC2 I've never seriously used it :o .

It took a second look for me to realize the playback feature above the status line. When you play two totally different mp3 files simultaniously you can get a very funny mixture :D.

On the first look It seems to work all fine, but I discovered some small glitches:
When a file is played and you use Swap Sides, the progress display doesn't get swaped. It stays on the original side.
When you play a song and then use the Reload Files button, the icon for Play/Pause doesn't get resetted.
When the focus is on the progress display the whole song can be made stutter by using the arrow keys on the keyboard.
What about a display of the over-all playtime of the file and the current time-position?
With focus on the progress display you can use the mouse-wheel in order to jump forward and backward in the song. But this only works in the first ca. 35 seconds.Bye
Christoph

[Erik]

When a file is played and you use Swap Sides, the progress display doesn't get swaped.
When you play a song and then use the Reload Files button, the icon for Play/Pause doesn't get resetted.


These will be fixed in the next release.


When the focus is on the progress display the whole song can be made stutter by using the arrow keys on the keyboard.
With focus on the progress display you can use the mouse-wheel in order to jump forward and backward in the song. But this only works in the first ca. 35 seconds.


This is the behavior of the windows control. You can actually drag the slider while it's playing also.

[Tom]

It's great to see the MP3 tool! Got a couple bug reports.

I unchecked everything but "data" in the comparison criteria. (This really needs a context menu item for check/uncheck all.) When I compared two known dissimilar files, the data line highlighted red showing the difference, and the incidental differences (song title tags, etc.) were highlighted orange showing their differences. So far so good.

Then I clicked Ignore Unimportant Differences and everything went black & white. All the highlighting disappeared, meaning (I presume) that they're all unimportant? When I disabled that option again, the orange items reappeared but the data lines remained B&W as if they were the same. (FWIW, one file was 7 megs and one was 7.8 megs.) Refreshing the files brought the red highlight back to the data comparison lines. If I understand it right, the orange highlighting disappearing is normal for the "IUD" feature, but not the red.

The other item is that the play controls are all dimmed (disabled) here. Any ideas on that one?

Otherwise, lookin' good so far!

[Erik]

This really needs a context menu item for check/uncheck all.

We'll add "Mark/Unmark All" buttons in the next release.


Then I clicked Ignore Unimportant Differences and everything went black & white. All the highlighting disappeared, meaning (I presume) that they're all unimportant?

Yes, that's what orange means.


When I disabled that option again, the orange items reappeared but the data lines remained B&W as if they were the same.

Only "Song Data" should be changing to same. This will be fixed in the next release.


The other item is that the play controls are all dimmed (disabled) here.

The problem is that we're asking Windows to play the file and it chooses to use an older player (Windows Media Player 6.4) which fails. We hope to have a fix in a future release.

[Tom]

We'll add "Mark/Unmark All" buttons in the next release. Thanks! I'm sure lotsa folks will appreciate that. :)

The problem is that we're asking Windows to play the file and it chooses to use an older player (Windows Media Player 6.4) which fails. We hope to have a fix in a future release. Sounds good. I tried opening an MP3 in Media Player 6.4 (mplayer2.exe) and it acted like it was playing but either did nothing or pegged the CPU. Do you think anybody has an MP3 codec that 6.4 would recognize?

Using the oldest NT-ready Media Player (mplayer.exe in system32) is worse -- it complains that it can't determine the filetype from the (MP3) extension. <sigh> I still keep it around for MIDIs, though, because it's much faster than any of the others for that.

[Tom]

The problem is that we're asking Windows to play the file and it chooses to use an older player (Windows Media Player 6.4) which fails. We hope to have a fix in a future release.

Just checking back on the status of MP3 playback. Have you guys considered incorporating the open source MPLAYER.EXE (http://www.mplayerhq.hu/design7/dload.html)? It seems to be very widely used.

[Tom]

.

[Aaron]

We have, though we can't implement just any open source project into our commercial product. This kind of change is quite large and would be scheduled in the same way as 'better zip support.'

WMP6.4 is not exactly what we are currently calling, but seems to have similar limitations/error handling as the method we are using. Most of the issues we run into deal with malformed tags in the mp3 files that cause problems.

[Tom]

We have, though we can't implement just any open source project into our commercial product.

Understood -- I realize there are licensing issues to consider. Some do permit commercial use, or maybe you'd only need to release the modified source of the player (if any) and not BC itself.


Most of the issues we run into deal with malformed tags in the mp3 files that cause problems.

Hmm. Is there any straightforward way to diagnose the issue here locally? I ask because I've been reporting playback capability being completely disabled on and off since the turn of the century. Heh! It's definitely not something so simple as corrupted tags on my system -- I've even tried files with all tags removed, or after processing with an MP3 "cleanup" utility to make the files meet specific standards. Controls remained dimmed/disabled.

What would you think about a configurable way to hand off both files to a couple instances of a player of one's choice from within the comparison module? That might let you reuse code that's mostly in place already. I know there're overarching business considerations that affect development decisions, but maybe that'd eliminate the need for a complete redesign if it's going to remain a lower priority. :)

BC3 sure is lookin' good, though!

[RunnerBiker]

Hi Tom,

I too have difficulty with some MP3 files. Here is a synopsis of what I found:

I am running Windows XP Media Center Edition (SP3 Beta) This system does not include WMP6.4, it uses MPlayer.exe (11.0.5721.5145 8/19/2004)

None of these lockup problems occur on my wife's computer. She is running Windows XP Home (SP3 Beta).

1) If the tag is large, the player controls are disabled (dimmed)
2) If the audio frames are preceeded by a LAME or XING or INFO frame, BC3 locks up and must be killed.

Notes about large tags. In my experimentation, I have altered an MP3 file by adding additional $00 pad bytes to the end of the TAG and preceeding the first audio frame. I have not found the "Exact" threshold where the problem occurs, but when the first music frame is at offset $1FF43 (Hex of course) the player controls are dimmed. (this also occurs on my wife's computer)

When the first audio frame is at offset $1F343, the player controls are enabled.

When the first audio frame is at offset $1F343 and it is preceeded by an INFO frame, BC3 works correctly, and enables the player controls.

When the first audio frame is at offset $1FF43 and it is preceeded by in INFO frame, BC3 locks up. (My wife's computer does not lock up, but the player controls are dimmed)

The audio frames in these test files are all identical.

All these test files play correctly when you launch them (Alt+A X P) from within BC3 or when you double click on them in the Windows Explorer.

All the symptoms are the same with BC2 and I have been working with Aaron since last fall on attempting to isolate the issue. Aaron believes (and he is probably right) that I have an errant codec installed that is causing the problem, but we haven't been able to isolate it yet.

Has anyone else with windows Media Center Edition experienced this type of lockup?

[Tom]

That sounds very thorough, RunnerBiker! Here're a couple things that might help you track down squirrely codecs. Marc Liron, Microsoft MVP, created Sherlock, a software-based "Codec Detective (http://www.updatexp.com/sherlock-codec-detective.html)". The app will point out the details of your codecs (audio & video separately) and highlight any problematic ones it finds, but doesn't offer any repair capability.

A good companion is the K-Lite Codec Tweak Tool (http://fileforum.betanews.com/detail/KLite_Codec_Tweak_Tool/1183386542/1). It seems to be a script-based approach created using Inno Setup and was just updated a couple of weeks ago.

[RunnerBiker]

Tom! Woo Hoo!

You are my hero.

I ran the CodecTweakTool and it "fixed" 23 errors in the registry.

Now BC3 doesn't lock up for me any more.

It still disables the play controls, but that seems to be consistent across all other platforms.

If you are interested, I snapped screenshots of all the errors the CodecTweakTool fixed. I can post these, but I'm guessing you don't really care what was screwed up.

Thank you again.

RunnerBiker

UPDATE 1 ==================================================

While BC3 no longer locks up, I cannot play MP3 audio files any more. Windows Media Player displays this error: Windows Media Player cannot play the file. The Player might not support the file type or might not support the codec that was used to compress the file.

I'll update this when I discover what needs to be put back.

UPDATE 2 ==================================================

I rebooted and can play MP3 files again. That is the good news.
BC3 locks up again, so I'll see what CodecTweakTool finds now.

[Tom]

I rebooted and can play MP3 files again. That is the good news.
BC3 locks up again, so I'll see what CodecTweakTool finds now.

Sorry to hear that it's turning out to be more of a challenge -- but it sounds like you're making progress! Don't forget that the tool has backup capabilities in case you need to undo any changes.

[RunnerBiker]

Yes, I saw the backup and restore functions, and I also saw the ability to create a TXT file with the details on all settings.

BAD NEWS -

Using the CodecTweakTool I disabled EVERYTHING.

Disabled ALL the filters
Disabled ALL the codecs
Disabled ALL the Direct Show objects
Disabled ALL DirectX Media Objects

I can not play an MP3, but I didn't expect to be able to.

BC3 still locks up. I have waited 30 minutes to see if maybe something was going to take a long time.

Is there anyone else out there with Windows XP Media Center Edition that can try one of these problem MP3 files?

[Tom]

Weird. What is it exactly that locks up BC3? Comparing 2 MP3s? I take it you rebooted after disabling all that stuff?

[RunnerBiker]

Yes Tom, I rebooted after disabling all that stuff, and by the way, Sherlock doesn't report any problems either.

BC3 (and BC2) lock up when attempting to open an MP3 file that has the characteristics I described earlier in this thread.

Highlight one MP3 file.
Press ENTER to open it in MP3 Compare.

The cursor changes to an hourglass for a few seconds and then the screen flickers and the cursor returns to an hourglass. If you hover the cursor on the "Cancel" Red X in the top right corner, after the flicker, the cursor becomes an arrow.

After the cursor becomes an arrow, clicking on the Red X in the top right corner causes Windows to react to a Not Responding Application, and lets you cancel it.

[Tom]

Sounds pretty frustrating, RB. Still, you've ruled out any codec issues, so you & Aaron can look elsewhere.

[RunnerBiker]

One additional clue is that the player controls are greyed out when the audio portion of an MP3 file begins after (or very nearly after) 128K into the mp3 file. (offset 20000 Hex)

This happens on my system (Win XP Media Center).
It happens on my wife's system (Win XP Home).
I believe Aaron told me it happens on his test system too.

What is special about the 20000Hex offset?

What Call did BC3 make to the Explorer shell to discover whether to enable the player controls, and what response code did BC3 get back that tells it to not enable the palyer controls.

When the BC3 player controls are not enabled, the MP3 file still plays successfully in Windows Media Player when you launch it from within BC3 (Alt+A X P) or by double clicking on it in the Windows Explorer. Why does BC3 think the mp3 is not playable?

Is there anyone else reading this who is running Windows XP Media Center who would like to try one of these "bad" MP3 files to see how your system responds to it?

[Aaron]

Hello,

We are using a Windows API call for the playing of media, which is returning to us that it cannot. Windows Media Player (most recent) probably has been worked on (by Microsoft) to handle trouble or otherwise wider range of files. The older Windows Media Player 6.4 seems to be closer in consistancy with what this API call can also handle.

Investigating this is on our wishlist.

[Aaron]

Are you still encountering any type of freezing? It sounds like from your later forum post that you managed to fix that and simply see the "button not enabled" which is the expected behavior.

[RunnerBiker]

Are you still encountering any type of freezing? It sounds like from your later forum post that you managed to fix that and simply see the "button not enabled" which is the expected behavior.

YES, I'm still getting lockups.

For a moment after running Sherlock the first time, I could open MP3s that have the 20000Hex offset issue, but as soon as I rebooted the lockups returned. Running Sherlock again did not help.

Like I said in my post on "06-01-2008 05:57 PM" I'm still getting lockups.

Thanks for your perserverence.

I sure would like to see someone else volunteer to test one of these files on a Windows XP Media Center Edition.

[RunnerBiker]

I finally figured out what was causing BC to lock up on certain files.

I used SysInternals: FileMon to watch what files BC accessed when it locked up. The last file it opened was aac_parser.ax. Then it went into an infinite loop reading 9 bytes from the MP3 file at the offset of the first audio frame.

This frame was an INFO frame and didn't really have any audio in it. I suspect that is one factor. The INFO frame is a recent addition to the MP3 encoding. It is possible that aac_parser.ax was not written to handle INFO frames.

The first time I reported the lockups to Scooter in October/November 2007, I had just upgraded an audio conversion program that I use. It is called SUPER (http://www.erightsoft.net/home.html). The behavior of BC2 changed.

Before I upgraded SUPER, when I encountered a trouble file, BC2 would not complete an MP3 compare, but it would respond to the ESC key and regain control. After I upgraded SUPER, BC2 would not respond to the ESC key (locked up).

I uninstalled SUPER, rebooted, tested, installed the previous version, rebooted and tested again but the new behavior was stuck.

What I discovered yesterday was that SUPER installs aac_parser.ax but it doesn't uninstall it. I deleted it and scoured it from the registry.

Finally after months and months, I can use BC2/3 without worrying about getting locked up. :D

Thanks for Aaron and Chris and everyone else who worked on this with me.

aac_parser.ax details:

Comments: Allows playback of ADTS files (normal extension .aac) in DirectShow players.
File Version: 1.1.0.0
Language: English (United Kingdom)
File Size: 81,920 bytes

[Tom]

Congrats, RB! Too bad it's not easier to troubleshoot that kind of stuff, but SysInternals really has done a lot to make it doable. The Win Driver Verifier (verifier.exe) is pretty good, too (although not designed for codecs, of course), but it's a pretty obscure tool and requires a lot of CPU. With all Microsoft's (and other people's) work on virtual machines, maybe there'll be a solution soon that'll create an automated, self-contained environment that would really stress-test these kinds of things without affecting the actual installed OS until you were ready to do some kind of repair.

You've really done quite a bit of detective work, sir!

[RunnerBiker]

Thanks Tom, This problem bothered me for quite a while.

Curiously, I had suspected Super from the start, since the behavior of the MP3 compare in BC changed for the worse when I installed an upgrade to Super.

Anyway - the problem seems to be gone now, I have used the MP3 Compare tool to analyze hundreds of MP3 files that would have caused me trouble and it has worked without any trouble.

[Chris]

RunnerBiker,

Thanks for posting the update. I'm glad you finally managed to solve the problem!

Also, thanks again for all the feedback you've given us on BC3. We really appreciate it.

[RunnerBiker]

The next challenge is to discover why sometimes the player controls are greyed out. The file is playable with Windows Media Player, but BC's player controls are greyed out.

[Erik]

As we've mentioned before, the controls are grayed out because we're asking Windows if it can play the file and it tells us it can't because it wants to use an older player. It's on our wishlist to figure out how to get it to use a newer player.

[RunnerBiker]

As we've mentioned before, the controls are grayed out because we're asking Windows if it can play the file and it tells us it can't because it wants to use an older player. It's on our wishlist to figure out how to get it to use a newer player.

Windows is probably consulting some codec (or another .ax file) to decide how to answer your query.

But the controls are only greyed out for some MP3 files, not all of them. I'm investigation for what is different about the MP3 files that it can't play. maybe there is a clue there.

Preliminary results show that the same files that locked me up before I discovered the aac_parser.ax connection are the ones that don't allow playback. The common feature of these files seems to be the first audio frame is at or after $2,000 hex. These files usually have a large picture (APIC frame) in the tag.

[Tom]

But the controls are only greyed out for some MP3 files, not all of them.

Not here -- it's probably been years since I last saw an MP3 for which the play controls were active. Naturally, that's caused me to use BC a lot less for that file format, representing about a 35% reduction of use overall. Instead of fixing BC's plugin, it might only take someone knowledgable to post how to set the right codec to be prioritized (in Windows).

[RunnerBiker]

Hi Tom,

Do you have an MP3 TAG Editor? Something like Tag&Rename? (http://www.softpointer.com/tr.htm)

Can you remove the tag from an MP3? If you remove the tag, are the player controls enabled?

Maybe you can post one of your MP3 files that has the player controls disabled, to see if they are disabled with my install.

[Tom]

Do you have an MP3 TAG Editor?
Yup -- I (mainly) use MP3/Tag Studio. The developer isn't much for keeping up with bug reports, but overall it's got a really good and versatile design. (BTW, I do love SoftPointer's AudioShell and use it all the time.)

Maybe you can post one of your MP3 files that has the player controls disabled, to see if they are disabled with my install.

Be glad to. I tried checking it with and without a tag, but there was no change. (Tag Studio offers a Shell Extension, so you can strip/copy/paste tags right from the Explorer context menu, among other things.) The one I'm posting is about a meg -- it's very low res, but it'll give you something to mess with.

The board won't let me upload it, but you can get it here (http://drop.io/tagtest).

[RunnerBiker]

I have MP3/Tag Studio too. It does some things better than Tag&Rename, but in general I prefer Tag&Rename. MP3/Tag Studio lets me scour all the files in a directory to remove undocumented frames like PRIV and NCON.

I believe Windows Media Player or one if its addons is writing the PRIV tags into the MP3s. I wish I could figure out how to stop that.

I downloaded your file. The player controls are enabled for me, and I confirmed that you removed the tag completely.

Did you see the discussion about Sherlock and CodecTweakTool earlier in this thread? Have you run them to see what they have to say?

[Tom]

I have MP3/Tag Studio too. It does some things better than Tag&Rename, but in general I prefer Tag&Rename.
Fair enough. :)

I believe Windows Media Player or one if its addons is writing the PRIV tags into the MP3s. I wish I could figure out how to stop that.
Me too! I guess you could try locking the files, since you don't need to edit them very often (if ever). It's pretty arrogant for WMP to modify files just because it plays them. :mad: MS Office apps do the same thing -- modify files just because you opened them, even if you don't make any changes. Definitely annoying, if for nothing else than the senseless additional file & drive fragmentation over time.

Did you see the discussion about Sherlock and CodecTweakTool earlier in this thread? Have you run them to see what they have to say?
See it? I started it. ;) They're not reporting any problems, and nothing else (I'm talking about over a dozen audio utils or players) has a problem with MP3s on my system. It's just that none of the others make it easy to do a side-by-side audio comparison.

[RunnerBiker]

See it? I started it. ;)
Of course you did. Sorry I didn't look back in the thread to verify the poster.

I did a trial install of BC3 (Beta 462) on my wife's computer (Win XP Home SP3). The player controls are not dimmed on her PC when analyzing the shenandoahlowres.mp3 file either.

I started collecting MP3 files that dim the player controls on my PC. I have about 25 right now. The unique thing about them is that the first audio frame is at offset 2,000(Hex) or higher into the file. If I remove the tag so the first audio frame is at offset 0 (Hex or Decimal), the player controls are not dimmed.

In three of the MP3 files, the first audio frame is past offset 2,000(Hex), yet the player controls are not dimmed. In fact one of those files has a huge APIC (picture) tag (1,393,575 bytes decimal). The first audio frame is at offset 15,453B(Hex) and the player controls are not dimmed.

On my wife's computer, all 25 files dim the player controls. The three that enable the player controls on my PC do not enable the player controls on her's. The player controls are enabled for the shenandoahlowres.mp3 file on her PC.

I tried to discover the author of the AAC_Parser.ax file but was unsuccessful. If that one was problematic, maybe another .ax file written by the same company is causing a problem too.

[Tom]

Of course you did. Sorry I didn't look back in the thread to verify the poster.
Heh! No harm done -- I'm just being difficult. :)

The player controls are not dimmed on her PC when analyzing the shenandoahlowres.mp3 file either.
By the way, the website kind of eats filenames apparently -- the original filename was "Shenandoah (low res).mp3". Oh well -- next time I'll try underscores or something.

I started collecting MP3 files that dim the player controls on my PC.
Well, everybody needs a hobby. ;) No, seriously, you've been very thorough in your approach -- but I'm not sure what else can be done.

I tried to discover the author of the AAC_Parser.ax file but was unsuccessful. If that one was problematic, maybe another .ax file written by the same company is causing a problem too.
That makes sense -- but heck, not including the DLL cache in Windows, there're 186 .AX files on my system, so lotsa luck making sense out of that collection. :cool: