Print

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

[lalittle]

I'm still getting long delays when browsing folders containing mp3s on mapped network drives.  Basically, when browsing folders containing mp3s on a network drive, I get LONG pauses before the songs are displayed -- MUCH longer than when browsing the same folder with MC10. 

The fact that MC10 does not have the same issue shows that this is not a network issue -- it has something to do with the way MC11 deals with network drives.  I'm using Intel NICs, with a 3Com switch.  No other apps (including MC10) show these delays -- the problem is unique to MC11.

Thanks for any help with this,

Larry

[JimH]

Larry,
If you're just mapping a network drive (not using Library Server), then MC doesn't treat it differently than a local drive.

Possibilities are:

1.  Your thumbnails aren't all built.  This would mean that the file would be transferred across the network to do it.

2.  Your thumbnails are getting deleted when you exit MC (setting).

3.  Analysis is being performed on the files (setting).

I'm fairly certain this isn't an MC bug.

[lalittle]

Larry,
If you're just mapping a network drive (not using Library Server), then MC doesn't treat it differently than a local drive.

But it really does seem to be treating them differently since the network speed does not appear to be a factor.  When browsing files on a network drive, it only uses a consistant 6% of the network bandwidth.  Compare this to the 75% to 80% of the bandwidth it uses when copying the same folder over to a local drive from within MC.  This means that the issue is not a "slow network" since the network CAN move data a lot faster -- it's just that MC is only "utilizing" a tiny percentage of available bandwidth when browsing.  This would imply that the slowness is caused by something OTHER than the network speed.  When you consider the fact that browsing files on the local drive displays the files INSTANTLY, it points to an issue with MC's utilization of the network.

Once again, MC10 does not have this problem.  There is a slight pause with MC10, but MC11 takes 3 or 4 times as long to display the files in the same folder.

Possibilities are:

1.  Your thumbnails aren't all built.  This would mean that the file would be transferred across the network to do it.

2.  Your thumbnails are getting deleted when you exit MC (setting).

Thumbnails?  I'm only referring to mp3s here -- are there "thumbnails" associated with mp3s?  That aside, this happens every time I close/open MC11, and I don't see any settings that tell it to delete thumbnails.

3.  Analysis is being performed on the files (setting).

Do you mean the "Replay Gain" analysis?  This is the only place I can find where "analysis" is done to the files, and I have the boxed UNchecked.  Is there someplace else that analysis is being done?

I'm fairly certain this isn't an MC bug.

I don't know how to "classify" this issue -- all I can say is that regardless of whether this is a "bug" or a "setting," it's a "problem" that I can't get to stop at the moment, and the length of the pauses is way too long to ignore.  In other words, the bottom line is that MC11 is doing this, whereas MC10 does not (on the same system with the same folders) and I cannot find any settings that prevents the long pauses with MC11.  The fact that at least one other person is reporting the same thing shows that it is not unique to me.

Did you try this at your end?

Thanks for helping out with this,

Larry

[lalittle]

UPDATE:  I think I may have found a "source" to this issue.

In my tests, I noticed that a few specific folders (albums) did not have the long pauses with MC11 -- they displayed in the same period of time that MC10 displays them.  I studied the tags, and at this point it appears that the crucial difference is CBR vs VBR mp3s.  If the was ripped to CBR mp3s, I get the long pauses.  If the was instead ripped to VBR mp3s, the songs are displayed much more quickly.  I switched to VBR a little while back, so most of my library is 160kbps CBR, but when I happen to highlight a folder/album that was ripped more recently as VBR, the extra long pause does not occur.  I can't say if this is the "only" difference yet, but it's the only difference I can find so far, and it seems consistant at this point with numerous albums.

This seems to point to an issue that is not due to a setting, but rather to some sort of issue in MC11.

Thanks again for looking into this,

Larry

UPDATE:  I found a single CBR album that does not have the long pause when displaying the songs.  Other than this one album, the pattern seems very consistant, but this of course breaks the pattern stated above.

[lalittle]

If yours is ticked, does unticking it help at all?

Thanks for the suggestion, but unfortunately this makes no difference in performance.  I don't think this applies to the situation since the files in question are not part of the library, so they can't be "missing."  The folders I'm browsing have files that are not part of the local library, so MC is not aware of what's in the folder until the folder is highlighted.  The problem is that it takes MC11 a LONG time to finally display these files (execpt, of course, on specific folders that are not effected by this issue, MOST of which use VBR instead of CBR.)

I still can't figure out why certain folders containing CBR files do not have this problem.  I've looked over all the tags, and can find no pattern to why one folder has a long pause and another does not.  All I CAN say at this point is that so far, NONE of the folders that contain albums ripped as VBR have the issue.  I think this is still an important clue regarding why the problem is occuring.

Thanks again,

Larry

[lalittle]

I'm still seeing this issue, and with both MC10 and MC11 installed on this system, I can really verify that the problem is new to MC11.  Using the same folder for testing (which is a single album with 19 songs on it) it takes a little over 5 seconds for the songs to display in MC10 when I browse to this folder in the "My Computer" branch of the tree.  With MC11, the same folder takes over 20 seconds to finally display the songs/files, which obviously makes browsing folders on a network drive really difficult since the response is so slow.

Thanks for any help in figuring this out.

Larry

[hit_ny]

Thanks for the suggestion, but unfortunately this makes no difference in performance.  I don't think this applies to the situation since the files in question are not part of the library, so they can't be "missing."  The folders I'm browsing have files that are not part of the local library, so MC is not aware of what's in the folder until the folder is highlighted.  The problem is that it takes MC11 a LONG time to finally display these files (execpt, of course, on specific folders that are not effected by this issue, MOST of which use VBR instead of CBR.)   (emphasis mine)

I have always found MC slow(er) when browsing unimported directories, that too for local drives. For network drives i'd imagine it'd be slower still. Since i only go into unimported folders to queue to PN, its not too much of a problem.

Imported was much faster. MC 11 has an explorer cache so the first time you browse a folder it fills it up, subsequently this same folder will load faster. Remember however that this cache is flushed when you shut down MC.

Are you saying that mC 10 was faster than MC 11 at browsing non imported folders ?

[lalittle]

Are you saying that mC 10 was faster than MC 11 at browsing non imported folders ?

Exactly -- and it's not just "faster," it's WAY faster.  As I mentioned above, a typical "large" non imported folder (19 songs) takes about 5 seconds to display the songs with MC10.  With MC11, the same folder on the same machine using the same network connection takes OVER 20 seconds to finally display the same songs, which is LONGER than it takes to literally copy the entire folder over to the local drive from within Media Center.  Something is amiss here since the network connection itself cannot explain the extreme slowdown -- not when copying over ALL the data from this folder takes less time, and when MC10 simply does not have this delay.

I believe it's a VERY important clue that NONE of the albums ripped as VBR have this issue -- it's only albums ripped as CBR that do this.  In other words, if an album was ripped as VBR, it does NOT have the delay when displaying the contents of the folder.  If it was ripped CBR, it "almost" always DOES have this issue.  I cannot see any pattern to why some CBR albums don't cause the issue, but this is fairly rare -- most albums ripped as CBR DO cause the delay.  This is somehow related to the issue, but I just don't know enough about the technical aspects of this program to figure out the connection.

Thanks again,

Larry

[hit_ny]

Do you store images inside the media files ? I dont mean associating but actually storing the images in the tags. What about bios, etc.

Tho i think if you did, it would be similar as with VBR files which you say load faster.

Can't imagine why VBR would load faster then CBR, sometimes VBR can be larger than CBR  in terms of file size ?

[lalittle]

Do you store images inside the media files ? I dont mean associating but actually storing the images in the tags. What about bios, etc.

Yes.  Two points to keep in mind, however, are 1) they are stored in both the CBR and VBR files, which behave differently, and 2) the EXACT same files are being accessed with MC10 and MC11, and MC10 does not have this issue.

Tho i think if you did, it would be similar as with VBR files which you say load faster.

Exactly.

Can't imagine why VBR would load faster then CBR, sometimes VBR can be larger than CBR  in terms of file size ?

It's unrelated to file size -- the sizes are relatively close between "alt--preset standard" VBR and 160kbps CBR.

This really appears to be some sort of "bug" with MC11.

Thanks again,

Larry

[JimH]

MC11 does audio analysis on import.  The default is off now, but yours may be on.  Try setting it to off.

[hit_ny]

Options->General->Import & Tagging->Automatically import files into MC

Checked or not ?

[JimH]

He said browsing, NOT IMPORTING

I saw that, but I think it may be relative. 

The speed issue is probably caused by files being copied from the server, modified and copied back.  Audio analysis is one possibility for that.

[lalittle]

MC11 does audio analysis on import.  The default is off now, but yours may be on.  Try setting it to off.

I'm not actually "importing" the files, but that aside, exactly where is the setting that you want me to turn off?  The only "analysis" I can find is the "Replay Gain" analysis, and this is unchecked.

That said, if you look at the combination of symptoms, I honestly don't think it points to a problem with extra analysis being done.  Consider the following two points:

First, the issue never happens with albums ripped as VBR files -- it only happens with folders containing CBR files, and there are even "some" CBR files that don't cause this issue.  If it was an "analysis" issue, the problem should be consistant, but it's not -- some folders containing larger amounts of data take only 5 seconds to display, while some "smaller" folders take over 20 seconds.

Second, if it was the "analysis" part of the process that was causing the delays, I should see similar pauses when browsing folders on the local drives, but this is not the case.

It's not hard to test your theory, however, by copying the folder mentioned above (19 songs ripped as CBR) to a local drive, and comparing the times it takes the two folders (one local and one network) to be displayed.  When I browse to the folder on the local drive, it opens basically immediately -- the songs are displayed in less than one second.  This demonstrates that the entire process of displaying these files -- INCLUDING the "analysis portion" of the process -- takes less than one second.  If I browse to the copy of this same folder on the network drive, it takes about 23 seconds for it to open.  If the analysis only takes less than one second, than the remaining 22 seconds of delay is due to something else.  Given than it only takes about 10 seconds for the entire parent folder and subfolder to be copied over the network, this leaves a full 12 seconds unaccounted for.  Note that I restarted the system in between the tests to make sure that there was no caching going on.

The speed issue is probably caused by files being copied from the server, modified and copied back.  Audio analysis is one possibility for that.

What "modification" are you referring to.  Are you saying that if I just "display" a folder (without importing or making any changes to the files), the files in this folder are actually modified?  Just to let you know, I tested the process on a network folder that I do not have write permission on, and it took the same amount of time to display as a folder where I DO have write permission.

If you consider that folders ripped as VBR do NOT have this delay, it seems to imply that this is not due to the process you're describing -- i.e. if it was the process of the files being copied, analyzed, and copied back, as you say, then the delay should be "generally" consistant with all folders.  Given the LARGE discrepency in the time it takes for different folders to display, however, (5 seconds for one folder compared to 23 seconds for another, both on the same network drive) it implies that there is something else going on.

Thanks again for helping get to the bottom of this,

Larry

[Alex B]

During the MC11 development Matt added several times new MP3 handling functions when people sent bad MP3 files for inspection. Is it possible that the VBR files you have are correctly ripped with LAME and contain better header information, but the CBR files are made with some other perhaps old encoder and MC uses brute force for getting the info when the files are browsed? At that stage MC reads the MP3 stream info besides the ID tags.

I have never encountered this problem because I rarely use MC for browsing unimported files.

[lalittle]

During MC11 development Matt added several times new MP3 handling functions when people sent bad MP3 files for inspection. Is it possible that the VBR files you have are correctly ripped with LAME and contain better header information, but the CBR files are made with some other perhaps old encoder and MC uses brute force for getting the info when the files are browsed? At that stage MC reads the MP3 stream info besides the ID tags.

100% of my mp3s were ripped with Media Center (starting with 9.1.)  As far as I know, MC has always used the LAME encoder, so would this eliminate this theory, or is it still possible that earlier versions of MC would have resulted in songs being ripped with "worse" header information?

That aside, doesn't the fact that the same files display immediately when browsed on a local drive show that this isn't the issue?  If it was a problem with MC having problems iwth the header info, wouldn't there still be a delay regardless of whether the files were on a network drive or a local drive?  It still "seems" like this issue is somehow related to MC's handling of files on mapped network drives.

Thanks,

Larry

[JimH]

MC handles a local drive and a mapped drive the same way.  It's done by the OS.

[lalittle]

MC handles a local drive and a mapped drive the same way.  It's done by the OS.

But look at the symptoms -- none of the theories presented so far line up with the behavior we're seeing.  The evidence suggests that MC is doing "something" different when viewing mapped drives.  I don't know about how the program works -- I'm simply noting the behavior, and the behavior is pointing to an issue between MC11 and mapped network drives.  If MC handled local and mapped drives the same way, then we should see the pauses on BOTH local and mapped drives.  If the issue had something to do with the network connection and not MC11, than it would happen with MC10, and with ALL folders on the network drive.

I find that with troubleshooting, I it works best to forget about what "makes sense" and instead just look at what's actually "happening."  It really appears that there IS something odd about MC11 and browsing network drives.

Thanks again for your help with this,

Larry

[JimH]

But look at the symptoms -- none of the theories presented so far line up with the behavior we're seeing. 

Copying a file from a network drive, modifying it, and copying it back is definitely slower than doing the same from a local drive.

I suspect it's a difference in how you have MC set up.  I may be wrong.

And, maybe you've said before, but any third party plug-ins?

[lalittle]

Copying a file from a network drive, modifying it, and copying it back is definitely slower than doing the same from a local drive.

Are you saying that simply using MC to browse a folder containing mp3s will MODIFY all the mp3s?  I don't understand this.  What is it doing to them?  I am not importing the files, and I don't have the "analyze" option checked -- I'm not even PLAYING the files.  Why would they be modified and copied back just by browsing to the folder?  And if they WERE copied back, why do the dates remain the same?

All that aside, I think you're forgetting to factor in ALL the symptoms, such as the fact that some folders -- including ALL folders containing files ripped as VBR -- do NOT have this issue.  You need to remember that if it was simply an issue of reading, modifying, and copying the files back over the network taking more time, then ALL FOLDERS containing mp3s would show this behavior.  How do you account for the fact that some folders don't have the issue?  Why would some folders containing LARGER amounts of data move back and forth over the network more quickly than other folders with LESS data in them?  This just doesn't follow when you look at all the evidence.

I suspect it's a difference in how you have MC set up.  I may be wrong.

Based on the evidence, I just don't see how this could be the case.  What setting in MC would make "some" folders take more than 4 times longer to display than others?  Why is it that I can re-rip the same songs as VBR instead of CBR and suddenely they move 4 times more quickly over the network even though the files are actually BIGGER?

And, maybe you've said before, but any third party plug-ins?

None -- it's a real clean installation.

Larry

[Matt]

My advice would be to import the files so MC doesn't have to do any work when browsing to them.

If you think it's only certain files, perhaps you could send a sample or two to matt @ jriver.com so we could benchmark MC 10 against MC 11 and see if we can reproduce it.

Thanks,
-Matt

[Alex B]

I decided to help, so I made a little test:


Drives & Devices browsing time of 100 MP3 files encoded with LAME & Helix (formerly Xing) encoders, using an empty new MC11 library


Local HD


VBR Extreme Lame, 100 files, 606 MB, time:  3.5 s

VBR -V90 Helix, 100 files, 412 MB, time:  4 s

CBR 160 Lame, 100 files, 405 MB, time:  7 s

CBR 160 Helix, 100 files, 405 MB, time:  6 s


A network path  (Win 2000 Pro NTFS share > Win XP, switched 100 MBit wired LAN, no other traffic)


VBR Extreme Lame, 100 files, 606 MB, time:  5 s

VBR -V90 Helix, 100 files, 412 MB, time:  5 s

CBR 160 Lame, 100 files, 405 MB, time:  1 min 40 s

CBR 160 Helix, 100 files, 405 MB, time:  1 min 35 s


I repeated this test several times (I restarted MC and made a new empty library each time). The local HD browsing times varied a bit from time to time so they are not reliable, but the network times were almost identical each time.

Edit: All files were encoded using the same APE source files.

[Alex B]

My advice would be to import the files so MC doesn't have to do any work when browsing to them.

If you think it's only certain files, perhaps you could send a sample or two to matt @ jriver.com so we could benchmark MC 10 against MC 11 and see if we can reproduce it.

Thanks,
-Matt

I think you can easily reproduce this if you make a VBR and a CBR file with MC and duplicate the files several times with Windows Explorer.

[lalittle]

My advice would be to import the files so MC doesn't have to do any work when browsing to them.

Without going into a long winded explanation, I don't want these files in the local library.  It has to do with how I manage files on two different systems and how I back them up.  Sometimes I don't want certain files in the libraries, but I still need to access/view them at times.  I like to use MC to do this rather than simply using Windows Explorer since MC shows the tags in the format I'm familiar with.

If you think it's only certain files, perhaps you could send a sample or two to matt @ jriver.com so we could benchmark MC 10 against MC 11 and see if we can reproduce it.

I'll be happy to.  Is there a size limit at that address?  I'd like to just send one of the entire folders I've been using to test so that we'd be on the same page.

Thanks,

Larry

[Alex B]

I don't think sample files are needed. This really seems to be a VBR/CBR issue that can be reproduced using files encoded with the default encoder.

My test files were freshly encoded with MC, a 40 track double-disk CD. I duplicated additional 60 + 60 files with Windows Explorer.

I made the 200 Helix encoded files just to make sure that the behavior is not depended on the LAME encoder.

[lalittle]

Alex,

Thank you for taking the time to do those tests.  It really helps when other people confirm this sort of issue on another system and lend their input to the subject.

The times in your tests seem to really point out the issue -- I hadn't tried such large folders.  It's interesting to note that it appears that the larger the folder, the bigger "percentage difference" there is in the times between displaying local and displaying network folders.  In your tests, the network drive took over 14 times longer to display the files compared to the local drive.

Larry

[Robert Taylor]

I know this is a long shot, but can you try setting your network card to NOT auto-negotiate the link speed/duplex? ie. specify 100Mbps / Full Duplex on BOTH machines, then each one individually...

I have found that with some network cards, they don't auto-negotiate correctly, and the more traffic, the worse the performance. I know if it was that, you would expect that it would affect both MC 10 and MC 11 the same, but maybe there is a difference with the way MC11 opens the files or something...

Hey..I'm grasping at straws (again)...but I have found this to be the source of some rather inexplicable behaviour...

cheers
Rob

[Alex B]

In my case the connections are auto-negotiated correctly as 100 MBit full duplex.

Browsing the smaller LAME CBR files was 20 times slower than browsing the bigger LAME VBR files. This was perfectly repeatable using the same two PCs and MC11. (5 s/100 s)

In the meanwhile I tried this with MP3 files encoded with the Fraunhofer encoder. This time the network browsing times were the same for VBR and CBR files, about 1 min 40 s.

Fraunhofer VBR files don't have a Xing header. Perhaps this has something do with the problem.

[Robert Taylor]

I've found that even though it APPEARS that they have auto-negotiated correctly, as the amount of traffic increases on the link, the performance drops terribly...

It takes 10 seconds to change the settings, it's worth a shot...if it makes no difference, nothing lost...

[lalittle]

I've found that even though it APPEARS that they have auto-negotiated correctly, as the amount of traffic increases on the link, the performance drops terribly...

It takes 10 seconds to change the settings, it's worth a shot...if it makes no difference, nothing lost...

I tried manually setting my cards to 100/full duplex and it made no difference.

That said, if the situation you're describing was happening -- i.e. if the network connection itself was slowing down and causing the delays -- why would folders containing VBR rips transfer fast and folders containing CBR rips transfer much more slowly?  The network speed shouldn't change depending on the encoding used for the file -- if it were a network problem, or any type of hardware problem for that matter, we should see the delays all the time.  We only see them, however, with certain folders and not others, and the behavior is totally consistant in this respect.

All the evidence seems to be pointing to MC11 as the culprit here.  It should be noted that no other application -- not even MC10 -- shows this behavior.

Thanks for the suggestions,

Larry

[Alex B]

In the meanwhile I tried this with MP3 files encoded with the Fraunhofer encoder. This time the network browsing times were the same for VBR and CBR files, about 1 min 40 s.

Fraunhofer VBR files don't have a Xing header. Perhaps this has something do with the problem.

I added Xing headers to the Fraunhofer VBR files with a MP3 tool. The browsing time of the same files reduced to 3 s. (100 files, 494 MB)

I tried this also with similar Ogg Vorbis and MPC folders (100 files, ~450 MB). The browsing times were very fast, about 2 s.

Without any deeper knowledge of the program internals it seems that MC11 trusts the header info if the browsed MP3 files are VBR and have Xing headers. Otherwise MC reads every single bit of the VBR or CBR MP3 files before it shows the folder contents, i.e. MC uses brute force.

Encspot shows that also the LAME encoded CBR files have Xing headers, but I don't know if that is correct. In any case that does not help MC11 in browsing.

BTW, it seems that my earlier guess was pretty much correct:

During the MC11 development Matt added several times new MP3 handling functions when people sent bad MP3 files for inspection. Is it possible that the VBR files you have are correctly ripped with LAME and contain better header information, but the CBR files are made with some other perhaps old encoder and MC uses brute force for getting the info when the files are browsed? At that stage MC reads the MP3 stream info besides the ID tags.

[Matt]

This will be fixed next build -- it turned out to be a Microsoft-ism.

For some reason opening a network file, reading a little (<1 MB -- we never read the whole file, but do read a little more for CBR than VBR), and then closing could take a long time to close.  It seems like the client-side reading code on Windows XP must read lots more than you ask for, and not be able to gracefully cancel on a close.

In any event, I think we have it worked around.

Thanks for all the help,
-Matt

[Alex B]

Thanks, Matt.

So my guess was only partly right.

I decided to start testing this because after reading this thread I quickly tried an old backup archive that contains 2350 various mp3 files in a single folder (it's a collection of unorganized "oldies" before the time I discovered MJ). Locally MC used 79 s for browsing the folder. When I tried the same on a network share I cancelled the process at 12 minutes. At that stage MC showed only about 800 of the files.


During my testing, I noticed that the Fraunhofer encoded VBR files showed different bitrates and playback times if the Xing headers were added:

FHG VBR   100 files, 494.1 MB - 06:05:48
FHG VBR + Xing header   100 files, 494.0 MB - 05:52:23

For that amount of files the difference is over 13 minutes. The FhG CBR files showed almost the same playback time with my Xing enhanced files:

FHG CBR 192   100 files, 484.5 MB - 05:52:31

The VBR and CBR files are made with a recent version of MMJB so it is possible that MC newbies have a lot of them. WMP 10 uses a similar FhG encoder, though it doesn't have a VBR option. FhG VBR + Xing header files are of course normally non-existent.

I made a package of three test files (vbr, vbr+xing, CBR) and mailed you a link if you like to check the files. You may want to check the network performance with these files too.

[Matt]

I think we have the performance issue licked.  Give the next build a shot. (hopefully out today)

MP3 length is more complicated than you'd think if the file doesn't have a Xing header. 

In these cases, we read the first 1000 frames or so.  We take the average bitrate of these frames to extrapolate a total length. 

This works perfectly for CBR. 

For VBR (without the header) the only sure system is a full file scan which would be too slow, so this is the next best approach.

This is also part of the reason that sample-perfect MP3 seeks are complicated. (which MC does)

Thanks for all your help Alex.

[Alex B]

I think we have the performance issue licked.  Give the next build a shot. (hopefully out today)

I'll not delete the test files yet (~4 GB)

MP3 length is more complicated than you'd think if the file doesn't have a Xing header. 

In these cases, we read the first 1000 frames or so.  We take the average bitrate of these frames to extrapolate a total length. 

This works perfectly for CBR.

For VBR (without the header) the only sure system is a full file scan which would be too slow, so this is the next best approach.

This is also part of the reason that sample-perfect MP3 seeks are complicated. (which MC does)

That's about what I thought.

Also Encspot reads the first 1000 frames unless a complete folder scan is forced or individual files are opened.

Would it be possible to add an exact bitrate/playback time calculation to the replay gain analysis? Because the complete files are scanned anyway that would not slow down things. In this way people who already have an MP3 library in a headerless VBR format could have correct time displays in MC.

[hit_ny]

I added Xing headers to the Fraunhofer VBR files with a MP3 tool.

Which tool did you use ?

Also is there a way to check whether headers exist in mp3s or not. I was under the impression that if the header was absent the mp3 would be invalid.

[Alex B]

Which tool did you use ?

VBRfix is one of the tools for that: http://www.willwap.co.uk/Programs/vbrfix.php

Also Foobar's Fix MP3 Header can do it, but I think you need to know the encoder delay value. For the current Fraunhofer encoder it is 672. This page has a table of some other values: http://mp3decoders.mp3-tech.org/decoders_lame.html

Also is there a way to check whether headers exist in mp3s or not.

E.g. VBRfix and Encspot can show header info.

I was under the impression that if the header was absent the mp3 would be invalid.

I suppose that depends on the player program used. I think the files can be played normally with most programs, but time displays and progress bars have problems.

Actually, Fraunhofer MP3 files have a VBR header too, named VBRI, but I don't know how it works and if MC uses it anyhow.

[Alex B]

... This page has a table of some other values: http://mp3decoders.mp3-tech.org/decoders_lame.html ...

I just noticed this on the same site:

http://mp3decoders.mp3-tech.org/decoders_mjb.html

MJ 5.0.601 was rated "Excellent". Nice screenshots too.   

[lalittle]

The 11.0.314 update fixes this "network delay" issue.  Thanks to everybody for their time doing tests and offering suggestions, and of course to the programmers who addressed this in a new release.

Larry

[Alex B]

A network path  (Win 2000 Pro NTFS share > Win XP, switched 100 MBit wired LAN, no other traffic)

VBR Extreme Lame, 100 files, 606 MB, time:  5 s

VBR -V90 Helix, 100 files, 412 MB, time:  5 s

CBR 160 Lame, 100 files, 405 MB, time:  1 min 40 s

CBR 160 Helix, 100 files, 405 MB, time:  1 min 35 s

I did some cleaning. Before deleting the test files I tried this again with MC 11.0.314:


A network path  (Win 2000 Pro NTFS share > Win XP, switched 100 MBit wired LAN, no other traffic)

VBR Extreme Lame, 100 files, 606 MB, time:  5 s

VBR -V90 Helix, 100 files, 412 MB, time:  5 s

CBR 160 Lame, 100 files, 405 MB, time:  12 s

CBR 160 Helix, 100 files, 405 MB, time:  12 s


- CBR is still a bit slower, but it is much better now.

[Alex B]

MP3 length is more complicated than you'd think if the file doesn't have a Xing header. 

In these cases, we read the first 1000 frames or so.  We take the average bitrate of these frames to extrapolate a total length. 

This works perfectly for CBR. 

For VBR (without the header) the only sure system is a full file scan which would be too slow, so this is the next best approach.

This is also part of the reason that sample-perfect MP3 seeks are complicated. (which MC does)

How about my suggestion?

Would it be possible to add an exact bitrate/playback time calculation to the replay gain analysis? Because the complete files are scanned anyway that would not slow down things. In this way people who already have an MP3 library in a "headerless" VBR format could have correct time displays in MC.