Hi, I'm not very happy with the seektool.
It should be very great for long mixes to jump from part to part. But it is not very useful that you must let the song play one time from the beginning to the end without scrolling and without loosing power. It would be much better if the player would store the parts of the song and completes it later.

It would also be great if you could choose in the setting if the round knob would be volume or scrolling. You could combine it with the status of the scanning, so when the song isn't completely scanned the knob is scrolling and if the whole song is scanned, the knob would be volume.
But v2.0 is sooooo great, I'm very thankful to the guys @ empeg/sonicblue. Go on this way.

The Seek Tool does not save partial information about the track because it must build the profile of the entire track before the partial information is meaningful.

Note that you can scan as much as you like within the track whilst it is building the initial profile. The algorithm is robust enough to cope with the information being filled in in an abitrary order. You are correct however about the loss of power resulting in the information gathered so far being lost.

The confusing change of the rotary knob from volume to seek whilst in the Seek Tool has been withdrawn for the next release. Instead the knob adjusts the volume whilst in the Seek Tool. Pressing the knob puts it into seek mode and the screen changes by highlighting the timecode bar the the top so that you can tell which mode you are in. Pressing the knob again restores the rotary function to volume.

Hope this resolves your issues,
Toby.

Hi,
thanks for your answer. You say that the algorithm is robust enough to handle the scrolling during creation of the profile. I think, the player collects information during playback. So why can't the player store the actual profile in a temp-file and restore it when the track is played again? It would be at the same state as before and could go on with profiling the track and if the profile is done, it could save it as the profile-file and everything is done.
Please tell me if I'm wrong

>>> why can't the player store the actual profile in a temp-file and restore it when the track is played again?


There are 2 reasons for this -> 1) Only a fixed number of variable data bytes are allocated to each track 2) The discs are mounted read-only except when synchronising with Emplode.

Whilst the profile for a track is being generated it takes up a lot more space than the completed profile. This is because for every new sample in a currently playing track it needs to calculate new means and standard deviations, and also to recalculate the number of standard deviations each already measured point equals now that the new sample has been added to the set. Once the profile is complete it can be compressed down to 2 bits at 128 pixels width = 32 bytes.

Your method of storing the partial profile in a temporary file would be feasible for the situation where you start profiling a track, power off, and power back on again to resume the profiling. It would not be feasible in a system where you are constantly changing tracks without finishing playing them as this would involve temporary storage to be allocated for an arbitrary number of tracks.

Please keep the ideas and questions coming.
Toby

Well, if you saved the uncompressed data while incomplete, you could just throw away old data when a new track starts, just to prevent the power-off issue. That might fix 75% of the incomplete tracks (probably much more in my case).

Ok, I have another idea. What about a "scan track" menu item that scans the song @ once? How long would this take for a mix of 120 minutes? I think, this would be the best way if one wants to have a long mix divided quickly.
regards

That could be quite useful. Build the data for a track as fast as possible instead of realtime.

- Trevor

Yes of course we have thought of this, it is an obvious idea. However the implementation would be somewhat involved compared to the current implementation. Imagine you are currently playing an MP3 and you want to scan another track (or the one you are currently listening to). This would not only require running 2 simultaneous decoders at different speeds, but also would require modifications to the existing user interface so that you could select the tracks to be profiled.

Nice idea, but unlikely to get implemented in the near future. For the moment you'll just have to leave your player 'scanning' overnight if you have a backlog of stuff to get through.

Hi.

Would it be possible to add the seeking data while uploading the tracks with emplode?
Also, let's assume that I want to keep my empeg running overnight, to complete as much scanning as possible, would it be possible that you add an option somewhere (possibly only available if a specific option is set in config.ini), like in "Settings" that disables sound output and visual calculations and speeds the scanning process up a bit? I.e. a special "scan" mode where the decoder works as fast as possible, but no sound output and no graphics (probably except for a progress indicator) are done?
Both options, the special scanning mode and the addition of that data via emplode, would be nice to have: The former would allow creating as much scanning data as possible during a night and on the empeg itself, while the latter would allow adding the data during upload, voiding the need to do the scanning on the empeg for newly uploaded stuff.

cu,
sven

This is really a nice idea.

I don't want to leave my empeg playing when I don't use it, because I don't want to hurt it too much. So why don't you let the emptool scan partitially or all tracks and synchronize the profiles with the empeg? The PC is (in most cases) much faster than the empeg and can do more jobs at the same time and it is much easier to implement it in the emplode gui.
Lets think about that...

regards

Both these ideas are feasible, and it should make no difference which one is actually employed. Apparently decoders should show a maximum of 1 bit error in each 16bit sample, so even if the profile was generated on a PC with a different decoder to the empeg the results should be the same.

If we had time I would recommend both these ideas be implemented as this would give maximum flexibility. However I fear the both are fairly large tasks and are unlikely to get done in the near future.

The power off problem I think could be fixed fairly easily, and if the implementation turns out to be straight forward I will try to get it into a future release.