21 Sep '14 - 13:06 *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: 1 ... 3 4 [5] 6 7 ... 27
  Reply  |  Print  
Author Topic: 3.6 reports, queries and bugs  (Read 114193 times)
Pike84
Posts: 1398


« Reply #80 on: 15 Feb '11 - 18:58 »
Reply with quoteQuote

OK, here's an update that adds a "NoPreload" XMPLAY.INI option to disable the preloading of the next track (unless crossfading is enabled)...

   www.un4seen.com/stuff/xmplay.exe

Note that it will also prevent gapless playback.
Maybe you guessed it already, but this isn't exactly what I was looking for...

As I said, I don't really understand the problem. Why can't you just make the player preload part of the next track, then anticipate/compensate for the buffer, so that the title change occurs at the same time as the track change?

It's not a big deal, and was partly because I had too big a buffer setting - I guess I'll just set it to minimum for now.
Logged
Chinese Sausage
Posts: 416


« Reply #81 on: 15 Feb '11 - 19:14 »
Reply with quoteQuote

Is the change on the same 3.6.0.8 version? :O
Logged
Ian @ un4seen
Administrator
Posts: 16891


« Reply #82 on: 18 Feb '11 - 13:40 »
Reply with quoteQuote

As I said, I don't really understand the problem. Why can't you just make the player preload part of the next track, then anticipate/compensate for the buffer, so that the title change occurs at the same time as the track change?

That is what should already happen, ie. the title display shouldn't change until the next track starts to play. To illustrate the problem you're seeing, perhaps you could make a little video (with sound) of it occurring?
Logged
Fraggie
Posts: 690


« Reply #83 on: 23 Feb '11 - 17:31 »
Reply with quoteQuote

If title tag is not present, but artist is defined, then the library will get full formatted string as the title instead just of the file name.

So with default formatting string, the library shows in this case something like "Artist - filename.ext" as the title.
Logged
Pike84
Posts: 1398


« Reply #84 on: 24 Feb '11 - 09:06 »
Reply with quoteQuote

That is what should already happen, ie. the title display shouldn't change until the next track starts to play. To illustrate the problem you're seeing, perhaps you could make a little video (with sound) of it occurring?
Ok, I'll try try to make something like that when I have the time.

As I said, when I stopped a track close to the end (definitely before the track change), I lost the following queue item as a result. My buffer setting was at 0.7s IIRC.
« Last Edit: 24 Feb '11 - 12:23 by Pike84 » Logged
saga
Posts: 1705


« Reply #85 on: 29 Mar '11 - 21:34 »
Reply with quoteQuote

I'm not sure whether the following problem is related to VBR files, so I've uploaded an example (saga-reconstruct.zip)...
I have a rather big mp3 file and after having played like half an hour of it, seeking forwards/backwards (using left/right key) always seeks to a point that is a few seconds before the current point, i.e. even with seeking forwards I get to a point that has already been played! Similary, the cue points in the the corresponding .cue file seem to get off-sync - XMPlay displays the last few cue points at a time that is off a few seconds from the intended cue time (confirmed with an audio editor).
Logged
Pike84
Posts: 1398


« Reply #86 on: 30 Mar '11 - 00:43 »
Reply with quoteQuote

This sounds like it could be related to the problem I described earlier. Sorry, that I haven't had the motivation to try and dig into it further Embarrassed - it's been such a minor nag.
Logged
Ian @ un4seen
Administrator
Posts: 16891


« Reply #87 on: 30 Mar '11 - 16:01 »
Reply with quoteQuote

I'm not sure whether the following problem is related to VBR files, so I've uploaded an example (saga-reconstruct.zip)...

Yep, VBR MP3 files unfortunately have poor seeking accuracy, and the larger the file, the less accurate it is. That's because an "Xing" seek table contains only 100 points. XMPlay will interpolate for positions between the seek points, but the table's file positions aren't very accurate either, being only accurate to within 1/256th of the entire file size. That means with a 74 minute and 100MB file (like yours), there is a seek point every 45 seconds, which has a file position that is accurate to within 390KB. So not very accurate Smiley
Logged
saga
Posts: 1705


« Reply #88 on: 30 Mar '11 - 18:02 »
Reply with quoteQuote

OK, I guess this also applies to the cue point seeking problem then? Or is seeking to cue points accurate?
Logged
Ian @ un4seen
Administrator
Posts: 16891


« Reply #89 on: 31 Mar '11 - 14:27 »
Reply with quoteQuote

Yep, the seeking accuracy will affect the CUE points too (seeking to a CUE point is basically the same thing as moving the position slider there yourself). XMPlay will use the VBR seek table to translate the time position to a file position but, as mentioned, that isn't very accurate.
Logged
piovrauz
Posts: 790


« Reply #90 on: 31 Mar '11 - 14:39 »
Reply with quoteQuote

mmm, does this affect just mp3 vbr or also other vbr lossy codecs? like musepack, or vorbis?
Logged
Ian @ un4seen
Administrator
Posts: 16891


« Reply #91 on: 31 Mar '11 - 16:39 »
Reply with quoteQuote

Other VBR codecs may have inaccurate seeking too, but that isn't necessarily the case. For example, OGG does have accurate seeking. I'm not sure about MPC, I seem to recall the decoder scans the file for seek points. Actually, as XMPlay is already scanning the MP3 file for the correct length, it may as well build a seek table at the same time. Here's an update to try...

   www.un4seen.com/stuff/xmplay.exe

Note the MP3 file scanning occurs after playback begins. That avoids playback being delayed, but it does mean that when resuming a saved position the normal (possibly less accurate) seeking will have to be used to get there.
Logged
moriez
Posts: 98


« Reply #92 on: 11 Apr '11 - 19:02 »
Reply with quoteQuote

SingleClickTray does not work here when another window is maximized and On top is unticked. I can only get it to work when I first press right mouse. Does anyone else experience this? I'm on XP.
Logged
Jimmy Neutron
Posts: 436


« Reply #93 on: 11 Apr '11 - 20:29 »
Reply with quoteQuote

SingleClickTray works as expected here.  I've maximized a Firefox window, and brought XMPlay up (and visible) and down (to the tray) with a single click.

Win 7 x64 desktop.

I'm not sure about XP, or if there's something else getting in the way for you.  Does your issue happen with ANY  maximized program, or just particular ones?

Edit: What version exactly of XMPlay?  Skin?  Vis?
Logged
moriez
Posts: 98


« Reply #94 on: 12 Apr '11 - 00:10 »
Reply with quoteQuote

With what I've tested any maximized window: apps or windows explorer does not matter. On the desktop it works flawlessly. It is not the Lithe skin as it's the same with the default. Neither is it something in the .ini file. I moved it away to test that. Version is 3.6.0.12 and no vis. It works fine when I tick ''On top'' but then it's on top what I don't want Smiley  Did you test without ''On top''?
Logged
Jimmy Neutron
Posts: 436


« Reply #95 on: 12 Apr '11 - 01:30 »
Reply with quoteQuote

Did you test without ''On top''?

I don't do "on top" ... it drives me nuts.

In the xmplay.ini I have SingleClickTray=1 and in the on-top section of the options screen, I have only "Always in Tray" checked.

Not sure what else you could try, except perhaps a different computer?
Logged
Chinese Sausage
Posts: 416


« Reply #96 on: 12 Apr '11 - 01:47 »
Reply with quoteQuote

Indeed, when on top is not checked, you have to double-click the tray icon to restore it, instead of a single click.
Logged
Pike84
Posts: 1398


« Reply #97 on: 12 Apr '11 - 23:55 »
Reply with quoteQuote

"SingleClickTray=1" works fine here on Win 7.
Logged
moriez
Posts: 98


« Reply #98 on: 13 Apr '11 - 16:15 »
Reply with quoteQuote

Indeed, when on top is not checked, you have to double-click the tray icon to restore it, instead of a single click.

You're on XP as well?
Logged
Ian @ un4seen
Administrator
Posts: 16891


« Reply #99 on: 13 Apr '11 - 16:29 »
Reply with quoteQuote

Do you have the "Always in tray" option enabled? If so, double-clicking (or single-clicking if "SingleClickTray" is enabled) can both restore and minimize XMPlay. So perhaps what's happening is that when you first click on the tray icon, XMPlay isn't yet minimized (it's just covered by other windows), so it becomes minimized at that point and you then have to click again to restore it.
Logged
Pages: 1 ... 3 4 [5] 6 7 ... 27
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.19 | SMF © 2013, Simple Machines