Print

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

[floppydisc]

Hi,

I have a small problem: I have many large MP3s (large = over 100MB, i.e. over 1 hour of music). When I want to scroll the playback position to - lets say - 40 mins, it takes several seconds up to several minutes until the player reached that position and continues playback. Until it reaches the position, it nearly locks up. I *guess* the problem lies deep in the playback engine and this behavior may not be avoidable when listening to VBR encoded files (as I guess that you can't determine the fileposition offset from the time) but I think for CBR there should really be no problem to instantly jump to the file offset and continue playing.

Btw. my files are stored on a network server (which may explain the minute-long delays) but for example foobar2000 or VLC handles the position change instantly - so it IS possible

I hope that is a small fix that can be applied to the version 11. Otherwise I would be happy if you atleast take it into consideration for MC12.

[floppydisc]

*bump*

[modelmaker]

This must be either a server issue or your system. I've just been playing  a 1 hour long nugsnet 128CBR mp3, jumping arouund with out problems. I also tried a 2hr 320 VBR mp3 with no problems scrolling ahead. This is from a local library.

[floppydisc]

As I said - it works perfectly with foobar2000 or VLC or Windows Media Player ... so it's definately not a server problem. (at least it is not only a server problem )

[Alex B]

I don't have that problem with my big album image MP3 files. I can play them using a network share without any seeking problems. It might be slightly slower than from a local HD, but nothing like you explained.

Are you using the Library Server or a network share directly? If you are using a network share have you imported the files to the MC library? MC does MP3 bitrate and length analysis when new files are browsed the first time, but that should not slow down things after the playback has started. MC has also sample-accurate MP3 seeking. Not many programs can do it. Perhaps that combined with something specific to your setup makes the problem appear.

Also, are using the latest MC build?

11.0.314: (9/1/05)

1. Fixed: Some MP3 flavors would take a long time if on a network.

Edit. Fixed a logical error. (I suppose the sample-accurate seeking takes place everytime the files are played.)

[floppydisc]

Yes, it's a network share and yes, I'm using the latest version (I also hoped that fix would apply to my problem). All the files I'm playing are imported into the library and I have played most of them at least once - so Media Center "knows" these files exactly

To be more precise, here is what I do and what happens: I double click the file to be played (with a length of over one hour) inside Media Center (from the library). It begins to play immediately. Now I scroll the position bar to 50 mins, but I still hear what is currently playing at the position (for example at 10 seconds), but I can't do anything in MC - it freezes. After some seconds the music stops and maybe 30 seconds later the playback continues at the new position (50 mins) and MC unfreezes.
When I do  the same in Windows Media player for exmaple, I open the file, set the position bar to 50 mins but it immediately continues playback on that position - no freezing, no waiting.

[hit_ny]

Options->Playback->Audio->Output->Output Mode Settings->Buffering

Try reducing buffer to a very small amount (smallest is 0.05 seconds) and see whether it makes a difference. The idea is that MC is more responsive then.

[JimH]

Take a look at this thread to see if you can spot anything:

http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=24031;start=0

If the file is on a local drive, do you still have the problem?

Also, please copy your system info from MC Help and paste it here.

[Alex B]

Options->Playback->Audio->Output->Output Mode Settings->Buffering

Try reducing buffer to a very small amount (smallest is 0.05 seconds) and see whether it makes a difference. The idea is that MC is more responsive then.

That might be worth of trying. However, I guess too small buffering can cause the playback to skip on LAN.


floppy,

What are your exact playback options (track switching, seek, buffering, output mode, etc)? I could try the same settings.

As Jim asked, can you exhibit a similar, but smaller in scale, difference between the player programs if the files are on a local HD?

BTW, what is your network setup? I have a 100 Mb switched and wired LAN.

[floppydisc]

Ok I copied the file over to my HD. It did not seem to have that problem, but then I tried to jump from the beginning of the file to 1 hour, 50 min - that caused a delay of 2 or 3 seconds. So the problem is the same - just faster
It seems as if it is reading the whole file until it finds the right position, instead of just jumping to the right spot. Btw. the network is 10Mbit (theoretically 100Mbit, but the server is a 100Mhz pentium 1, so it is far too slow for 100Mbit )

Here my system info:

Code: [Select]

Media Center Registered 11.0.314 -- C:\Programme\J River\Media Center 11\

Microsoft Windows XP  Workstation 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 1699 MHz MMX / Memory: Total - 523 MB, Free - 188 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1612 (xpsp2.041207-1145) / Shell32.dll: 6.00.2800.1643 (xpsp2.050311-1242) / wnaspi32.dll: N/A
Ripping /   Drive E: TEAC    CD-W516EB         Mode:Normal  Type:Auto  Speed:Max
  Drive F: PIONEER DVD-ROM DVD-116   Mode:Normal  Type:Auto  Speed:Max
  Drive G:   Mode:Normal  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: No /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No 

Burning /  Drive E: TEAC     CD-W516EB          Addr: 1:0:0  Speed:16  MaxSpeed:16  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: No /  Normalization: None

I also tried reducing the buffer, but with no significant change in the delay. I already changed Seek/Stop/Switch to Gapless and I use "Wave Out" as output mode. Anything else that could cause trouble?
How does MC handle the files? Does it use it's own mp3 decoder or a codec from the system? In the latter case the codec could be responsible for the problem.
I'm currently converting one of those mp3s into an ogg file. I'll post back if the ogg file still causes the same trouble.

[hit_ny]

It seems as if it is reading the whole file until it finds the right position, instead of just jumping to the right spot. Btw. the network is 10Mbit (theoretically 100Mbit, but the server is a 100Mhz pentium 1, so it is far too slow for 100Mbit )

There is no way to do this with mp3 cept read from start to desired location hence the name sample accurate seeking. winamp (not sure bout win media player) guesses so its not that accurate. Yes there is a slight delay but it's preferable to be exact. If you want to compare against another player, try FB2k instead.

I think a 10Mbit network should be adequate if all you are doing is playing mp3s, at most that would require 320kb/s.

Skipping around means a faster network will bring more across in shorter time, assuming your server is not too loaded and has enough memory to file serve, 256MB would help. It's ideal if media can be stored locally, much better performance overall.

Here my system info:

Code: [Select]

Microsoft Windows XP  Workstation 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 1699 MHz MMX / Memory: Total - 523 MB, Free - 188 MB

..and I use "Wave Out" as output mode. Anything else that could cause trouble?

I found when i upgraded to XP from W2k, Direct sound worked best, much lower resource usuage. On W2K Wave out was all that worked.

[floppydisc]

hit_ny: As I said: I tried, WMP, FB2k and VLC - and they had no probs. But I think your explanation seems to be reasonable. If this is really the case, I would like to see that as option in further versions of MC so that I can decide whether I prefer accuracy or speed

Edit: the conversion to OGG just finished. With that file, there is no delay - not even when played over the network share. The funny thing is, the ogg file is VBR encoded ...

[floppydisc]

Any further ideas? As it seems to be a problem specific to MP3 playback ...

[hit_ny]

hit_ny: As I said: I tried, WMP, FB2k and VLC - and they had no probs. But I think your explanation seems to be reasonable. If this is really the case, I would like to see that as option in further versions of MC so that I can decide whether I prefer accuracy or speed

It's interesting you don't find any noticeable delay with FB2k since it implements sample accurate seeking as well. I don't believe its instantaneous,  how long does FB2K take on your machine to seek to say an hour into the mp3 vs. MC ?

Also how much memory do u have on that P100 (ur server) ? Though this might be moot if FB2K works as well as you say.

Edit: the conversion to OGG just finished. With that file, there is no delay - not even when played over the network share. The funny thing is, the ogg file is VBR encoded ...

Ogg allows sample exact seeking without having to read from the beginining.

With mp3s, what matters is when you load it up and skip around, MC or FB2K needs to build up a seek table. So the next time you skip around it will be faster as it knows where to go. This applies so long as we are playing this mp3. If you play another mp3 after, then go back to the last one, the same process needs to be done again.

[floppydisc]

Ok I take a stopwatch to get the time it takes to jump from the beginnung to 1 hour:

MC: After 10 seconds the playback of the current file stops (seems to be some kind of buffer) and after 57 seconds I finally reach the 1 hour mark in the mp3 and playback continues at that position.

FB2k: 3 Seconds

VLC: No delay at all.

Remark for fb2k: The playback thread seems to stop or freeze when I jump to a position in a song. So what I did to get a convincing result was to start fb2k, load the file, hit play, set the position to 1 hour, hit stop immediately, fb2k freezes for 3 seconds then, now I can hit play again and foobar jumps to 1 hour without delay. (If you count that play-jump-stop-play-jump it takes perhaps 5 seconds instead of 3).

[hit_ny]

Ok I take a stopwatch to get the time it takes to jump from the beginnung to 1 hour:

MC: After 10 seconds the playback of the current file stops (seems to be some kind of buffer) and after 57 seconds I finally reach the 1 hour mark in the mp3 and playback continues at that position.

FB2k: 3 Seconds

So what I did to get a convincing result was to start fb2k, load the file, hit play, set the position to 1 hour, hit stop immediately, fb2k freezes for 3 seconds then, now I can hit play again and foobar jumps to 1 hour without delay. (If you count that play-jump-stop-play-jump it takes perhaps 5 seconds instead of 3).

That's the buffer in both players.
In MC  Options->Playback->Audio->Output->Output Mode Settings->Buffering
In FB2K Preferences->Playback->Full File buffering.

Can you try to make MC's buffer as close to what you see in FB2K. I think 3 seconds to wait for such an operation seems like the lowest limit that can be achieved on your system with a sample exact player. Try the above test again.

Unless you prefer to use VLC, in which case when you can configure MC to send to it when you think there is going to be lots of jumping to and fro

But i think we would all prefer to use MC all the way through. I don't have network drives but many people on this board do, if more people could write back about what wait times they are seeing with large mp3s and skipping ahead.

It might help to identify if there are any improvements that can be made to the MC Playback engine.

[floppydisc]

Changing the buffer did not change anything. After 10 seconds playback stop, aber 57 seconds playback at new position.