avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Friday December 2, 2022, 3:48 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Jan-S [ switch to compact view ]

Pages: [1]
Post New Requests Here / Re: REQUEST: audio comparer
« on: December 05, 2008, 12:46 PM »
I don't have any specific examples. I just think it would be a cool program to experiment with. It would be interesting to see if it's possible to remake songs etc out of a set of sounds.
Without any examples, I don't have anything to test the approach against. Besides, you would need a really huge set of sounds then, if you try to recombine it out of 1 second pieces (which is quite long) and still be able to recognize anything!

I guess you can use midi as an example. All of the wav to midi converters that are available now compare tones rather than sounds. All they find is the basic notes. But I bet you could convert the actual sound of the wav file to midi with a program that compares the sounds of all combinations of 128 notes on 128 instruments.
Intelliscore Music Recognition claims to be able to recognize more than one instrument, at least if you tell it which instruments it should listen to, but you still have to manually tweak the MIDI file afterwards (the results are not perfect).
The approach of comparing sounds might theoretically work, but there are several challenges: Firstly, you have to find metrics that are robust to noise and to overlayed instruments playing at the same time. For instance, if you are looking at an excerpt of the file where both a piano and a guitar play a chord composed of several notes, the comparison will find good matches for several piano, guitar, banjo, ukulele or harp sounds. It's difficult to construct the metrics such that the piano and guitar matches are guaranteed to produce the highest scores.
Secondly, you do not only have to recognize which instrument is playing which note, but also when the note is played. Unfortunately, the frequency information is imprecise when you increase the timing resolution and vice versa (this is related to the Heisenberg uncertainty principle). Finding a way to recognize a note attack so the comparison can be applied at the right position is not easy - especially as there are instruments (like violins or flutes) that do not have a sharp attack and can play a note at almost arbitrary length.

A funny approach would be randomly generating MIDI files, comparing their sound to the original song and evolving the best matches by recombination and mutation (Genetic algorithms). But probably this will take ages because the searching space is too big :)

I was wondering: does sound have a dithering effect? Like would playing a really high note followed by a really low note equal a note in the middle?
I don't think so. Even if you play two pure tones at the same time, the brain is quite good at figuring out the two tones. You can try this with an audio editor that is capable of generating sine waves. Or maybe I misunderstood your question?

Post New Requests Here / Re: REQUEST: audio comparer
« on: December 05, 2008, 10:24 AM »
Hey! This sure sounds interesting... anybody willing to discuss possible metrics?
On a first thought, I'd split the file into N pieces, multiply each piece with a Gaussian window function to reduce the sharp edges, perform a fourier transformation of each piece and calculate the absolute values, getting rid of the phase information. These transformed pieces can be treated as N vectors.
To obtain the similarity of two files A and B, I'd calculate the vectors for both files, compute the cosine of the angles between each of the N pairs of vectors (dot product divided by norms), add their absolute values up and divide the result by N.
This would give a number between 1 (sounds are identical w.r.t. the metrics) and 0 (sounds do not have anything to do with each other).
For N=1, this metric would be based solely on the frequency components of the sounds; for greater values of N it would include timing information (i.e. when did particular frequencies occur).
Any comments on this approach? Other ideas? Questions?

@agentsteal: Are the sound files all the same format (sampling rate, bit depth)? Mono or stereo? I'd be interested in experimenting with the metrics, but not that interested in figuring out how to parse or resample the files.
What kind of sounds do you have? Could you provide some examples (denoting whether you would classify them as similar or not)? This would be important to test and tune the metrics.

Having read an article about the consequences of Vista's DRM / Content Protection mechanisms several months ago (A Cost Analysis of Windows Content Protection), I've decided not to seriously try Vista. I will probably have to install it for testing purposes sooner or later, but when I drop XP somewhen it will be replaced by Linux, not Vista.

Hi Archee, and welcome! Nice to see you over here.

I've just played the game again and it is still funny as hell :)! Actually it would give a great screensaver (computer vs. computer, infinite number of bouts), or, even better, a toy robot ;D. I'm curious about what other releases you have in mind - the engine looks very capable (actually I found the secret before even having played a single round, because I was so fascinated of the menu :-[).

Please keep us informed if you create another game or tech demo or a Sumotori Screensaver!

Living Room / Sumotori Dreams - a hilarious 3D sumo game in 87kB
« on: April 23, 2007, 05:47 PM »

I've just found a very small, but very funny game - it is called Sumotori Dreams, weighs 87 kiB and was the winner of the Breakpoint 2007 96K game competition.
It features two artificially intelligent sumo robots (at least one of which is to be controlled by a human player) and a quite realistic physics engine. The best part is not the battle, though. As the author describes it:
The bout starts when both players touch the ground, and ends when a player falls to the ground or steps outside the circle. [...] Then players stand up and bend for greeting. (may be difficult)

Well, just see for yourself ;)

Find And Run Robot / Re: v1.13.01 test
« on: October 11, 2006, 03:16 PM »
can you try version 1.13.02 [...]
the problems you identified should be fixed.
Wohoo, everything works again 8)
I can't tell how I missed FARR during these two days (I didn't backup the old version before installing the new one). Thanks for fixing it that fast! :Thmbsup:

Find And Run Robot / v1.13.01 - incremental search broken
« on: October 09, 2006, 05:55 PM »

I've just upgraded to v1.13.01 (from v1.09.04). After figuring out that I need to supply the '-standalone' switch now (I'm using LiteStep to launch FARR on WIN+D) I've run into a serious problem: Incremental search doesn't work anymore.
FARR doesn't attempt to search for matches when I enter some characters, and pressing RETURN just launches the first result of the history (let's call that behaviour State_A). If I disable "Incremental search on each keypress" it works as intended. Enabling the option again while FARR is still running (or disabling it, restarting FARR and enabling it afterwards) returns to State_A.

--> Interesting: I've started FindAndRunRobot.exe without any command line parameters now.
Method_1 = Doubleclicking the tray icon
Method_2 = Right-clicking the tray icon and choosing "Show Find and Run Robot (hit break key)"
Method_3 = FindAndRunRobot.exe -standalone

Method_1 opens FARR, displaying the history and performing incremental searches without any problems.
Method_2 opens FARR without history and without incremental searching. Entering something and pressing return causes FARR to search for that keyword, afterwards FARR is in State_A (i.e. changing the search phrase and pressing RETURN launches the first item instead of starting a new scan).
Method_2 + opening and closing the options without any changes suddenly reveals the history, and FARR is in State_A.
Method_2, entering something, pressing RETURN and clicking the options button while it is still scanning causes a deadlock (hour glass cursor and no reaction on any input, but 0% CPU and apparently it can still redraw its window when its dragged out of the screen and back). --> Not reproducable.

--> Interesting, too:
Method_1, entering an alias: All items are displayed as usual.
Method_2, entering an alias and pressing RETURN: All items are displayed as usual. Well, almost. The list has the right number of entries (as far as I can guess from the height of the list), the entries are in the right order, I can right-click them or drag&drop them whereever I want - but they are all invisible (plain white with no icons and no focus rectangles). FARR is in State_A.
Method_3, disabling "Incremental search on each keypress", entering an alias and pressing RETURN: The same as for Method_2, but FARR doesn't get into State_A (i.e. I can enter a new search and pressing RETURN will search for that keyword unless it's an alias (in which case FARR displays its invisible items (ingenious alliteration) again)).

Anything else you'd like me to try? :huh:

/edit: If you can provide the last two betas I'll happily try them to find out which version introduces the bugs.

Find And Run Robot / Re: farr v2 planning - use cases and action idea
« on: September 07, 2006, 08:11 AM »
3.-other things i would love to see include the ability to select and execute multiple results. ie i have an alias similar to the default search alias where it would be great to type in alias query and then open the website/files for the first three results
I think this is solved very well in the current FARR release: in Options -> Interface you can define a modifier for "Launch and stay open". I'm using CTRL for that, so to open the first three results I would hit CTRL+1, CTRL+2, 3. :Thmbsup:

In FARR2 this could work the same way. If you already entered an action and are looking for files, Modifier+Number could execute this action on each file seperately. If you selected a file first and entered the action modifier to browse for actions, Modifier+Number could execute different actions on the selected file (can't think of a use case scenario, though).

Living Room / Re: Texture Generators/Creativity Exploration
« on: July 30, 2006, 03:32 PM »
This thread reminds me of a cool shareware I've tried several years ago (somewhen in the last millenium). It was called Infinity Textures and offered a lot of generators, filters, presets and, most importantly, seamless drawing tools (you were working on a tiled, infinite canvas) so you could give the texture some sort of shape before working with filters.
I would recommend Infinity Textures to anyone but I can't - it has been renamed to TextureMaker :). TextureMaker seems to offer some amazing features - extracting a texture from a photo while adjusting perspective and removing illumination gradients, generating seamless animated textures using particle systems, preview textures mapped onto 3D models, a terrain renderer similar to good old TerraGen (something you can definitely waste your time with :D)...
So if you're looking for a professional texture generator / editor with some additional time-saving and time-wasting ;) features this seems to be worth a try (30€ for private use, 65€ for commercial use, and there's a feature-limited freeware, too).

Am I alone in feeling like most of this is stuff that should be provided at the OS level? [...] This is the kind of thing I was hoping for with Vista.
Actually you're not the only one, Microsoft is working on a new file system called WinFS that ought to be included in Vista but has been delayed. WinFS is a file system based on relational databases - so actually you could tag any of your files with any kind of metadata and be able to search for email messages of all people that show up on at least two photos taken in France. 8)
See wikipedia for details.

/edit: Oh, I see you're actually well informed of this.

Developer's Corner / Re: What do I do now?
« on: May 23, 2006, 03:33 PM »
In order to protect the software from being cracked, you may consider offering a freely downloadable demo version with some features disabled (i.e. the related code is not even compiled into the demo) and offer the full version for customers only. This is simple, but uncrackable, and if your program is not bigger than a few MB, hardly anyone will be annoyed because of having to download it again after purchasing it.

Registration service: I'm quite happy with share-it. If you take the time to code a script that handles the software delivery (i.e. generates an account for your download area), you don't have any work with processing the registrations. Share-it even offers to automatically deliver the full version of your program by email or by generating a temporary download link.
I think most other services mentioned above offer such functionality, too.

Advertising: Try Google AdWords. You can start with a small daily budget and the minimum bid (cost-per-click). Make sure to address potential customers, and only potential customers - your target is not to lead as many people as possible to your website, but to lead interested people to your website. Otherwise you will end up paying for visitors who didn't want to spend money anyway. E.g. you should use specific keywords, exclude the term "freeware" from your keywords and don't use an advertising text in the sense of "Great program for anyone! Click Here!"

9. Disallow executing results on ALT + F-key (for example, ALT+F4)
Agreed! I would like to see an option to disable the function keys as a replacement for the digits. Too often I get the context menu of the fourth list entry when I want to close FARR.

1) when you type the modifier prefix, the results switch to a list of matching actions until you finish typing the modifier
This is my favorite. You will not need the file list when you've indicated you want to type an action by entering the special action prefix.

Another quick "extra prefix" would be to read all phrases that begin with an uppercase letter as modifiers ("Kill" is a modifier, "kill" is not).
Cool idea. I don't think I would use it as for me it's faster to type a dash before the action, but it wouldn't hurt to offer this as an option (it's just as easy to parse).

Please, please do not let the tab key have anything to do with the functionality of v2.
-QuickBrownFox (May 21, 2006, 01:27 PM)
In the TAB-based approach mentioned above the TAB key was not used for navigation, but to confirm an action or select a file you want to perform an action on. RETURN should still launch a file and TAB is another easily reachable key which could be used to push items on the "command stack". Please see the thread I've linked in my last post to learn more about this idea.

In the case of finding a file and performing a different action on it, in ADDITION to being able to type the action followed by the file (or however you choose to make the syntax work)... about searching for the file in the normal way, selecting it by cursor keys, and then typing the action you want to perform on it. As a keypress other than enter is detected another text box pops up to the right of the item and searches for actions relevant to the file type similarly to the way that the main text box searches for files.
-QuickBrownFox (May 21, 2006, 01:27 PM)
This is a very important point. You should be able to browse for a file and decide about the action afterwards. I think when you highlighted a file and start typing, FARR should put the filename into the list (just the filename, without path - this means FARR has to map the abbreviated form to the full file name, internally (maybe it should even just keep the part of the filename you entered)) and append a space sign, the command prefix character and the first character you typed, filling the result list with matching actions.

I think I'd still prefer the TAB-based approach discussed in the last thread, but I see that the special character approach is easier to implement.
You should be able to customize this character, though, as not all keys are easy to reach on all keyboards (e.g. I would prefer a dash as a command prefix). Secondly, the existing group aliases should still be accessible without a prefix. And thirdly: Do you still think of the multilevel keywords that would go with the launch bar features (being able to specify menus and submenus and access them via toolbar buttons or by typing them into the search field)?

when evaluating each of the files, it could see what the right-click context menu allows to do with that file (this is the hard part, i think), and generate a bunch of actions
Cool idea. With the TAB-based approach it would be enough to only do that for a single file after the user chose a file and pressed TAB. But even with multiple files this is not hard to implement as Windows takes care of finding actions that apply to all files in a certain set of files (try selecting multiple files of the same type and then multiple files of different types in Windows Explorer and compare the context menu) - @mouser: contact me if you can use some example code I've written in Delphi.

There are some interesting new ideas in this thread. jgpaiva (#64) already replied to most of them exactly as I wanted to before reading hist post (the SPACE problem; scoring for the task switching to give running instances a lower or higher score; being against two edit fields; not requiring aliases to begin with a special character). :D

Although I'm going to partly repeat myself and jgpaiva, here's what is important for me.
1. When using FARR, I want to type down what I have on my mind. This implies:
- A single edit field. I don't want to have to take care of which field I must type in.
- No special command character, whether prefixed or appended.
- No predefined action (e.g. starting the line with 'open ') that I have to delete first.
2. Multiple verbs should be possible - they would match the submenu grouping of the launch bar features (like 'mp3 enqueue').
3. Multiple params may be useful. Their order should be fixed (e.g. param1 always comes before param2), but the command verb should be allowed to change positions with the first param (e.g. 'cmd param1 param2 param3' should equal to 'param1 cmd param2 param3'). Note that the verbs and params should still be separated by a special key like TAB / ENTER / #, I'm just using spaces here for readability.

I agree that having a default command like 'open ' pretyped in the edit field would help new users to understand they can also enter commands instead of filenames. This wouldn't interfere with my personal requirements above (which are just the way I personally would love to see FARR) if the 'open ' default text would be preselected so I would overwrite it anyway. This wouldn't have any advantage when parsing the command line, but it would help new users. -> Even better: In Windows XP and above you can have edit fields display a grayed text that is automatically deleted when... oh well, when the edit field gains focus. Forget it. :D

Making it possible to switch between double editbox mode (the default setting for beginners) and single box mode ('classical') would be perfect. :up:

Maybe we could start to collect commands we would like to have (although of course they could all be implemented by launching external applications, some of them should be included in FARR and the list of commands might reveal parsing problems that have to be considered by mouser when designing / defining the concepts).
- copy <file> {copies a file reference to clipboard so you can paste it in Windows Explorer, creating a copy of the file)
- cut <file> {copies a file reference to clipboard so you can paste it in Windows Explorer, moving the file)
- kill <task> {kills the task - should list both window titles and executable/module file names}
//edit: Ah, while I was still typing, jgpaiva had the idea of collecting actions, too. Good luck for your exam!

The problem i was referring before with the {tab} action, is that tab's would have 2 different uses aren't very well specified, and i don't think it should behave differently when there is a file or an alias, or when it is the first item or not, the idea is make everything work the same way, i think.
That's right, it might be confusing. However, I wouldn't know how to make it faster / easier. The different TAB behaviours between files and aliases/keywords are just because we can speed things up for commands as we don't need to distinguish between 'open it' and 'use it (= combine it with a command)'.

My point is that seen that you will be using the arrows to select the result from the result list, the way to access it should be with the down arrow (or up arrow, to start at the other end of the results, maybe).
When you are using the arrows, the down arrow should bring you to the list as usual. But I wouldn't like to have to use the arrows to browse to the 5th entry to select it. We definitely need a way to use the number keys - still being able to distinguish direct execution of a file entry from pushing it to the command stack.

Or instead, use a number combined with a modifier, something like that.
This would probably be less confusing and maybe should be the default behavior. If you did a search for files and want to execute an action on a file (but not on the first match), you have to press MOD+# (with MOD being configurable as it already is) or use the arrow keys and press TAB. However, I personally am slower at using a combination like ALT+# (firstly it is slower to type and secondly I have to remember if to use ALT or CTRL or both) and would rather like to press TAB followed by the number. TAB would still have the single meaning of "combine commands" or something like that - it is always used in this context. This doesn't need to be the default behaviour, though.

I think that esc to go back one level is a good idea, and shift-tab is even better, since you make the queue with tab, it makes sense to dequeue it with the oposite :Thmbsup: :Thmbsup:
Actually it's not my idea, I've read that SHIFT+TAB is used by Quicksilver (in another thread). And again, ESC is easier to use than a key combination here, but nothing speaks against using both shortcuts here, does it?

@allen: ACK. All these things should be available in context menus, too - e.g. doubleclicking a file entry will open the file while the context menu will have a submenu like 'with this file do >' (or similarly). And just entering a program name and pressing RETURN should still immediately execute it because this is what users will expect.

How about having a "launch" button and a "with.." button? :D
Good idea, too! Pro users should be able to remove them, though :D And the buttons could have a "return key" and a "tab key" icon so users will eventually try them and notice how much easier this can be ;)

You could also use the status bar (or an optional "help" bar) to tell the user what is currently possible - e.g. when a command is currently the first item, you could display "RETURN/SPACE/#: executes command, TAB/arrow: go to list" and when a file is the first item: "RETURN/#: launch file; TAB: select file to use with command" and so on.

i think your solution also has a problem:
Even to select the first result, you have to do {tab}{tab}.
Some combination like ALT+# would be ok, too, but I personally would rather tap tab (pun intended) twice instead of having to press a key combination. But as we are speaking of the command selection, # or RETURN alone would launch the command. The only problem with # / RETURN launching the entry directly is when selecting a file because we may want to execute a command on the file instead of executing it. That's what I suggested TAB, # for.

As for dequeuing: Both ESC and SHIFT+TAB should dequeue the last added item and return back to the appropriate list (e.g. when you are in 'mp3 > enqueue > [?]', ESC would return to 'mp3 > [?]'). Or did you mean something else?

What about nested commands in this two-box solution (see jgpaiva's post above)? I think they would be great, especially as they would nicely match the ideas of being able to add buttons and submenus to FARR to use it as a launch bar, too (submenus = nested aliases).
I think a single edit box would be better, and I also think you should be able to specify the command first OR search for the file first.
When you start typing, FARR just matches the string against all keywords (aliases, commands) and all files - the commands should have a special icon (user-definable) or maybe even some special text attribute (bold, underlined, colored). They should not have to begin with a special character (like *), but of course you can create your commands like that if you like it.
Pressing RETURN launches the first entry - no matter if it is a file or a command. Pressing a number key also immediately launches the specified entry.
Pressing TAB+TAB uses the first file, meaning you are then presented a list of possible actions. If you want to take another file and execute a special command on it, it should be possible to select it using the arrow keys and press TAB, or, which would be much faster, press TAB, followed by the number (I think it's important not to be forced to use the arrow keys).
FARR would have to display the current command / params stack (as suggested, but a textual representation should be enough), marking the position that needs to be filled next.

To execute jgpaiva's example 'mp3 enqueue somemusic.mp3' the following sequences would be possible:
"mp3" -> FARR recognizes the keyword and shows the 'mp3' command in the list, continuing to scan for files matching "mp3" nevertheless
TAB -> FARR adds 'mp3' to the command stack, empties the edit box and displays something like "mp3 > [?]" in the status bar; the list is populated with mp3's subcommands
"enq" TAB (or press #) -> Assuming that 'enqueue' was the first match for "enq", FARR adds 'enqueue' to the command stack, empties the edit box and displays "mp3 > enqueue > [?]" in the status bar; the list is populated with the last used files
"some" -> FARR lists all files that match "some" (BTW it could even list all matching directories or keywords that modify the search path)
# -> FARR adds the specified file to the command stack, finds that no additional params are needed and executed the command

Another sequence:
"some mp3" -> FARR lists all files that match "some mp3" (e.g. this could mean *some*mp3*)
TAB -> FARR switches focus to the list and shows that it is awaiting a file to be used with a command, e.g. displaying "? > [?]"
# -> FARR adds the specified file to the command stack (on the second position), restores focus to the edit box and clears it, displaying "[?] > somemusic.mp3". The list is populated with available commands that take a file as one of their params - this is transitive, e.g. 'mp3' is listed because it offers subcommands that accept a file param (or maybe 'mp3 > play' and 'mp3 > enqueue' should be listed immediately?)
"mp" -> FARR limits the list to all fitting commands that also match "mp"
# / Return / Space / TAB -> FARR takes the specified cmd / first cmd / first cmd / switches focus to list, adds 'mp3' to the command stack (first position), finds that 'mp3' is not satisfied with just a file param and thus clears the edit box (restoring focus to it), displaying "mp3 > [?] > somemusic.mp3", populating the list with all commands in the 'mp3' menu that accept a file param
"enq" & RETURN / # -> inserts 'enqueue' into the middle command stack position, finds that the command is complete and executes it

I think this is better because you can start typing rightaway what you have on your mind, not taking care of which box you are in. Also this approach would allow for commands accepting multiple params (e.g. two files or a file and a folder). It would be perfect if you could access submenus without having to press TAB, e.g. "mp3"-TAB-"enq" should equal to "mp3 enq" - when generally listing these commands in the format "mp3 > enqueue", "mp3 > play", "mp3 > mute", "inet > apache > start" etc. this should be possible without special treatment of commands.


Firstly I want to mention this is a really great idea and very well implemented. Will be a real timesaver for me as I'm too lazy to organize my start menu and am mostly using WIN+E to launch a new instance of Windows Explorer and navigate by keyboard to what I wanted to launch.

A small bug I've noticed in version 1.07.21 (sorry if it was mentioned before, I couldn't find it using the forum search):
When you add a search folder ending with a backslash, e.g. "D:\", and have 'Result Label Path' set to 'relative to search', the first character of the directories is always missing in the result list - e.g. I get a result "opera.exe" located in "pera" (instead of "Opera").
Suggested solution: Find and Run Robot should drop a trailing backslash when I'm adding a new search folder.

Best regards,
Jan Schl├╝ter

Actually most duplicate file finders are able to find all kinds of duplicate files as they are comparing the binary contents of the files. So even if you do not have a specific scenario like mouser's example, you may be able to free a lot of disk space by just cleaning your music collection, picture collection or download folder from duplicate files. It is important to note that although you will have duplicate files in other directories like your Windows or Program Files directory, most of them are needed by these programs and your system - so you should never scan your complete hard disk and delete all duplicates you can find.

mouser's example of downloading files and adding them to your collection is something DoubleKiller Pro can handle much better than other duplicate file finders: As you can see in brotherS' screenshot of the Scan Options page, there are two separate directory lists that perfectly suit this task. By adding the directory of new files to the upper list and your collection to the second one, DoubleKiller Pro scans the new files for duplicates and also checks if any of the new files is already contained in your collection. Imagine you have a collection of 10,000 wallpapers, just stumbled upon a new site and downloaded 100 wallpapers from it. Other duplicate file finders like NoClone would have to check all 10,100 files for duplicates while DoubleKiller Pro would only compare the 100 files against themselves and against the collection, which is obviously much faster.

DoubleKiller Pro also beats the competition in other tasks, like scanning MP3 files for duplicates: Using the advanced content comparison options, you can compare the MP3 files against each other without regarding the information about song and album title, composer and so on (so-called ID3 tags). This way DoubleKiller Pro will also find MP3 files that have exactly the same MP3 content, but a differently spelled or omitted album title. (Details are described in the usage examples chapter of the help file.)


Congratulations to mouser for this really great site, I'm very impressed by the effort he and other contributors are putting into this project - I think it's certainly worth it! It's amazing to see this concept works so well.

I'm glad to tell you that I'm now supporting the November Fundraiser with a couple of free licences for DoubleKiller Pro, a flexible duplicate file finder, and a 30% discount available to all members.

I can just repeat what Martin said: Have a nice celebration month!

Pages: [1]