0.6 public test

Topic: 0.6 public test (Read 68126 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

0.6 public test

Reply #325 – 2003-04-18 20:13:57

Quote

This is a very minor nitpick and it might be intentional, but play_control::WINDOW_HIDE isn't quite the same as minimizing Foobar 0.6b22 via the minimize button/menu item. The big difference is that the window state isn't serialized. So if a component calls WINDOW_HIDE, Foobar will reappear at next launch.

In order to serialize the window state, I had to do this:
Code: [Select]
ShowWindow(service_factory_base::get_main_window(), SW_MINIMIZE);
play_control::command(play_control::WINDOW_HIDE, 0);
It would also be nice if WINDOW_HIDE could be set, with a -1 accessor to get the current state (ala PLAYBACK_SHUFFLE). Not a big deal, though, since you can get the window style and figure it out for yourself.

i think it is OK to use raw win32 api calls on main window handle for querying status (at least for now).
no idea whats wrong with window state being serialized, all "remember window position" stuff uses GetWindowPlacement()/SetWindowPlacement() in win32 API (called on startup/shutdown, so no extra state change handlers needed).

0.6 public test

Reply #326 – 2003-04-18 21:54:01

Do you think that "%_isplaying%" has a chance of becoming available to plugins? I was thinking it would be nice to be able add "$if(%_isplaying%,'*',)" to some plugin display strings. (namely, mine )

0.6 public test

Reply #327 – 2003-04-18 22:19:30

no, you have to code it yourself (compare to get_now_playing() and set proper extra params for title formatting)

0.6 public test

Reply #328 – 2003-04-18 23:18:43

I figured as much, but thought I might as well ask.

0.6 public test

Reply #329 – 2003-04-19 03:09:03

Whats the 4/18/2003 version of foo_input strd on Case's site all about? What's different?

0.6 public test

Reply #330 – 2003-04-19 03:11:15

Bug in album-replaygain scanning 48Khz mp3's?

I have an album that scans correctly except for one track, but only on the album scan.. if i scan it for per-track gain it finishes and writes the values to the file, but if i select 'scan as album' it encounters an error on that file and stops.

The problem file is a 48kHz 128kbps MP3, joint-stereo, padding size 1 byte, frame size 1 152 samples (if that's any help; I think that's the only 48kHz file I've tried to replaygain yet). There appear to be two synch errors at the very end of the file (MP3Utility [http://www.geocities.com/mp3utility/] reports one at 99%, which could actually be the APE tag, mp3utility is oldish; the MAD winamp plugin reports 2 of them just before playback stops; foobar's console doesn't report anything. There is no audible defect in the file in any player.).

Upon trying this with a different file, also 48kHz but 160kbps this time, the same thing happened: the file scans properly in per-track scan, but the scan process encounters an undescribed error in the last part of the file if I try to scan it as part of an album, which leads me to wonder if it's a generic problem with 48kHz files... this second file also had a synch error at the very end, so in the interests of controlled experiments I went & found a utility for fixing such errors. I found something called MP3Fixer [http://www.nomadness.feck.net/MP3FIXER.zip] and ran it on the file.. it said that there were no synch problems but chucked some bytes out of the file anyway. Tried the replaygain scan again, same "An error occurred while processing files", so it would seem to be 48kHz that sets it off (I've known it to be ok with synch errors in files of other samplerates).

here's what the console has to say about it:

Code: [Select]

INFO (CORE) : attempting to edit file info : file://M:\The Doors - (Self-titled)  The Doors - Take It As It Comes.mp3
INFO (CORE) : file info update successful on : file://M:\The Doors - (Self-titled)  The Doors - Take It As It Comes.mp3
WARNING (foo_input_std) : mpeg stream error at 2762710 bytes, attempting resync
INFO (foo_input_std) : mpeg stream resync successful

(the total filesize is only 2 152 308 bytes, so that console output is kind of weirdish... also, that warning doesn't show up when I play the file, only when I'm replaygaining it)

Does anyone know the exact calculation foobar uses for the album replaygain scan? I exported the replaygain numbers for some other albums (ones that scanned correctly) into a spreadsheet to see if I could find a calculation for the album gain based on the individual track gains (and fill in the values for that pesky file myself), with no luck yet. The closest I've gotten is to take the average [mean] of the track gain values and subtract half a standard deviation, but that doesn't seem to be quite it :P

Note: scanning as album does seem to work when I only scan the one 48kHz file -- but not much point to that :)

ach.. sorry this is so long... I'm trying to be thorough :P

0.6 public test

Reply #331 – 2003-04-19 04:11:06

Minor bug with beta 22:

When fb2k is minimized and the track changes to an off-screen entry, the playlist won't scroll to make it visible. It works when the window is visible.

0.6 public test

Reply #332 – 2003-04-19 05:18:18

Quote

Does anyone know the exact calculation foobar uses for the album replaygain scan?

The gain scanner collects the gain information for the entire album as if it were a single file. Obviously, this cannot work unless all files are the same sample rate. Now, if these are all from a CD album, why are they not 44.1KHz? Or is it a live recording amongst a set of rips? Or do you even know? ;P

0.6 public test

Reply #333 – 2003-04-19 07:15:30

Quote

The gain scanner collects the gain information for the entire album as if it were a single file. [...] Now, if these are all from a CD album, why are they not 44.1KHz? Or is it a live recording amongst a set of rips? Or do you even know? ;P

Cuz I'm a pirate and I downloaded them off a p2p network; there, are ya happy? :P
I have no idea how that came to be 48kHz... maybe some person had a DAT source or something... or maybe they were just being stupid and did an analogue rip at 48kHz.. in any case, I still think it shouldn't trip up the scanner :P

as to the value produced for the album gain (and I realise I'm probably overlooking something important and making myself look foolish), why isn't it equal to the weighted mean of the individual track gains? i.e. for each track value multiply by the track length (say, in seconds), then add up all those products and divide by the total length of all the tracks? or is there something with logorithms I'm missing (cuz the gain values in are decibels)?

0.6 public test

Reply #334 – 2003-04-19 09:06:47

The scanner must be reset for different sample rates.

And as for the weighted average .... I dunno. Might have something to do with the scale not being linear, but I really have no idea, sorry.

0.6 public test

Reply #335 – 2003-04-19 11:25:16

Quote

as to the value produced for the album gain (and I realise I'm probably overlooking something important and making myself look foolish), why isn't it equal to the weighted mean of the individual track gains?

http://replaygain.hydrogenaudio.org//stati...al_process.html

Quote

Having calculated RMS signal levels every 50ms through the file, a single value must be calculated to represent the perceived loudness of the entire file. The above histograms show how many times each RMS value occurred in each file.

The most common RMS value in the speech track was -45dB (background noise) - so the most common RMS value is clearly NOT a good indicator of perceived loudness! The average RMS value is similarly misleading with the speech sample, and also with classical music.

A good method to determine the overall perceived loudness is to sort the RMS energy values into numerical order, and then pick a value near the top of the list.

0.6 public test

Reply #336 – 2003-04-19 19:33:17

Moneo, I believe you misunderstood what he meant. Goes back to another situation too. Perhaps someone could explain why you can't simply take existing track replaygain values and derive the album value from those values? Foobar rescans every track even if every single one has track values already when you do an album scan. Surely the track values in combination with the track lengths is all you need to calculate the album value, no? If not, why not?

<edit> ok, I tried an album I have with 16 tracks.

-9.75000 is album value according to foobar's album scan.
-9.33125 is straight average of the track gain values.

229 7.34   1680.86
382 9.3      3552.6
236 8.96   2114.56
223 7.38   1645.74
322 9.81   3158.82
242 10.16   2458.72
336 9.83   3302.88
380 9.62   3655.6
195 10.33   2014.35
198 9.64   1908.72
237 9.1      2156.7
325 10.9   3542.5
266 8.28   2202.48
309 11.02   3405.18
373 7.99   2980.27
202 9.64   1947.28

4455 secs total
41727.26 total

9.3663883277216610549943883277217 weighted average.

hmm, so much for that theory. I read that link before I tried this, but now after doing this and reading that page again I understand why it's calculated again. Because all rms samples get used, not just a track's track-gain. Nevermind

0.6 public test

Reply #337 – 2003-04-19 19:47:37

foobar2000 0.6 beta 22, after loading close to 4,000 files and adding them to the database, beta 22 has around 469MB of virtual memory used up, (maybe this is a memory leak?), either way it shouldn't have a footprint of that size at any time. foobar2000 remained open overnight after I loaded the files (it wasn't playing though).

- Mig

0.6 public test

Reply #338 – 2003-04-19 20:43:24

Quote

foobar2000 0.6 beta 22, after loading close to 4,000 files and adding them to the database, beta 22 has around 469MB of virtual memory used up, (maybe this is a memory leak?), either way it shouldn't have a footprint of that size at any time. foobar2000 remained open overnight after I loaded the files (it wasn't playing though).

- Mig

cant reproduce (loaded ~1000 files, VM size stays 5meg). what file types did you load ? do you have any third-party components installed ?

0.6 public test

Reply #339 – 2003-04-19 21:03:24

I only have 2 third party components installed, I loaded mostly mp3s, Maybe a few wavs.

The third party components i've got installed are:

foo_focus and foo_shizzle

Btw, I just re-loaded the files and my VM size becomes about 250mb.

I removed the 3rd party components and loaded up a directory of files that weren't already
in the database (which is enabled), they weren't all media files however, some were zip/rar/exe
and the vm size again rose past 200mb, (though only the media files were added (and for some reason .fla files)

- Mig

0.6 public test

Reply #340 – 2003-04-19 21:39:52

Well, foo_focus doesn't allocate any memory (if I recall correctly), and foo_shizzle is only allocating memory on open or refresh (and deallocating on close/refresh).

0.6 public test

Reply #341 – 2003-04-19 21:53:23

rar/zip readers eat a lot of memory for temporary data but i cant find any leaks, at least not with rar (working on it)

0.6 public test

Reply #342 – 2003-04-19 22:04:33

Adding arbitrary directories (e.g. Visual Studio; Microsoft.NET) seems to cause some memory leakage. Adding the VS.net directory caused the memory use to rise by several megs (from 7.3 to ~12) and only drop part of the way back down on completion (to 8.6). Adding other arbitrary directories seemed to have the same effect (i.e. an additional rise). These numbers are from the task manager, though, and I know the numbers it reports can be misleading.

0.6 public test

Reply #343 – 2003-04-19 22:20:25

Quick question (suggestion?)
Do you think you might change the playlist dragging behavior anytime soon? Selecting and dragging tracks doesn't work quite as well as one might hope. Dragging upward causes the dragging action to stop as soon as the selected track(s) reach the top of the list "window". Same thing when dragging down, although depending on how it's sized, there might be a "magic spot" where jiggling the mouse will cause the list to scroll, thus allowing the selections to move down a bit more.

0.6 public test

Reply #344 – 2003-04-19 23:30:35

beta23 posted, one confirmed memory leak in rar reader fixed

0.6 public test

Reply #345 – 2003-04-20 02:18:23

Quote

Quote
Support for m3u files with URLs using extended characters (question marks, ampersands, etc...) broke at some point between .586 and .6

An example would be:
http://domain.com/artist/album/filename.mp...?stream=1&log=0

Also support for choosing to display #EXTINF from m3u playlists would also be cool.

that url seems broken, returns some HTML crap.
whoever maintains that site should be told to obey some F. standards (most of shoutcast clients out there just assume all http:// urls to be mp3 thanks to nullsoft and their l33t softw34r des1gn sk1llz)

domain.com/artist/... was just some bullshit example I used instead of my real website. It was an example of the syntax of the kind of link I was talking about, not an actual web-based mp3-via-cgi url.

0.6 public test

Reply #346 – 2003-04-20 08:50:27

if you want me to research the problem, then at least post an example that is supposed to work.
anyway, this kind of shit has no chance of working correctly if eg. user decides to limit added files to *.mp3

0.6 public test

Reply #347 – 2003-04-21 11:56:01

With latest betas when saving playlist as .m3u8, result is utf-8 but has no '#subsong' and 'file://' stuff.
Has it been dropped recently?

0.6 public test

Reply #348 – 2003-04-21 12:34:50

yes, m3u8 format will probably go away, #subsong stuff got removed for compatibility with other players.

0.6 public test

Reply #349 – 2003-04-22 13:55:30

Just noticed a minor "bug". First, put transparency on and disable buttons. Then, if you enable buttons, they get shown pretty ugly at first:

This gets fixed as soon as you select foobar's main window as the active window.

Notice