1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
Future Thoughts
===============
random thoughts for beyond 0.3.0; many of these are user requests.
migration
* allow import of libraries/ratings/covers from amarok, etc.
* we could use the 0.2 -> 0.3 upgrade framework, assuming it is made flexibly
enough.
UPnP support
* client
* server
* very few players support this yet
* rb has a plugin (python)
DAAP Server
* would require patching python-daap to have server support (likely doable)
Playback Bookmarks
* allow bookmarking places in the audio file for quick jumping to
* UI? (custom cairo-drawn on/near progressbar?)
* auto-save last position
* partially available in 0.3 with the Bookmarks plugin
Cuesheet support
* parse the CUE at import time and create separate tracks for each entry. This
would require extra work in both ``player.py`` and ``collection.py`` to
handle it correctly, but allows full integration with the rest of exaile's
features.
* CUE information could be encoded into the URL using a scheme like
``/path/to/a/file.flac#CUE:1`` where ``1`` is the track we want to play
from the CUE. The player will then take care of translating the progress
and other data from gstreamer's raw values to ones appropriate for the
subsection of the file we're actually using.
* Very bad idea, the reason why we have special issues with ``#``'s in
filename -- Abhishek Mukherjee
* nonsense, if done right there's no reason it can't work. the splitting
on #s just needs to be handled sensibly. eg. only split if it comes
after an extension we recognize.
* edge cases that may need special handling:
* gapless transition between tracks in the same file
* probably not a huge issue - we'll jsut have two handles open to the
same file. less efficient than using the same handle, but much easier.
* if the transition is between sequential tracks, might be worth
optimizing to just keep using the same AudioStream
Shuffling albums
* no clue how to do this UI-wise
Library structure handling
Allow exaile to manage the libraries' on-disk structure. Use ex-falso-like
system to determine path. We can then expose in the UI methods of copying
tracks directly into this structure. This is espeically useful for import
from mp3players/cds/etc if multiple libraries, allow to specify one as
default or to choose which to use on each copy.
Video Playback:
* this could be tricky UI-wise. perhaps expose as another tab in playlist
view, with buttons to go fullscreen or separate window
* use for video podcasts, have a separate collection for videos too
heavyweight for main perhaps? (is it possible to do as plugin?)
Audiobooks
* allow a separate collection for audiobooks
* plugin?
* could be automatic by grabbing eveything with a genre of audiobook, but
give right-click menu for manual marking as well.
* automatically save/resume position in book (thru bookmarking support above)
Keybindings
* allow full user-customizable keybinding support
* should be doable both when exaile has focus and globally (with different
settings for each, though in the same settings pane). This will merge the
functionality of the "Keyboard Shortcuts" plugin (xkey.py) from 0.2.14 into
exaile itself and add a dep (optional?) on python-xlib.
musicbrainz
* use for cd tagging
* allow analysis and retagging of files, like picard?
* gst has an ofa element for scanning we can use.
custom stemming
* e.g. allow trimming of 'A', not just 'The'
* allow locale-dependant stemming?
Context tab/Revamped Info tab
* simple method:
* allow plugins to make new tabs
* move wikipedia info out to a plugin
* allow putting info panel as a whole or individual tabs into the side
panel
* advanced method
* add an optional amarok-style context tab to the side pane
* should also allow sub-tabs like amarok's lyrics tab
* allow hiding of current now-playing area if context tab is enabled? may
not be feasable as we put buttons in that area too.
* all previous tabs in the info tab can now be added as a pane in this
context tab (or a sub-tab), siliar to how amarok's context pane is
divided
* the info tab would work the same way as the new context tab, except as
its often wider it should allow panes to be in multiple columns
* eg: you might have the first tab within info display statistics and
releated artists, each in its own column, while another tab might
show wikipedia info accross the full width
* in this setup, the context tab would always change to match the current
song while the info tab would remain the same. This eliminates the
current solution of using a checkbox, which takes up space and is easy
to forget about
* in either case, we could also provide last.fm album/artist info
Content-Matching (involved)
* matching tracks based on tag content rather than loc.
* useful for: detecting moves withing the library, xspf playlists
* ?match by everything or a subset? if x% is the same? efficiency?
* needed? amarok handles files moving by storing the file's checksum in
the db, perhaps we should do this too.
* hash only part (eg the last 512k), to make it fast.
* problem: some tags (id3v1, some apev2) are stored at the end of the file.
most tags (id3v2) are at the front. we don't want to hash the part
containing tags, as that could change unlike the actual music itself.
* hash based on filetype? eg for id3v2-using formats like mp3 use the
last part, and for ones like wavpack that use the end of the file, hash
the front?
Advanced DBUS
allow greater freedom to query, eg allow listing artists, albums in
collection, searching collection, etc.
Sorting Tags
* ID3 defines TSOA/TSOP/TSOT for purpose of "sort" tags,
* we should support them.
* MP4 also provides such tags
* are there ones for APE/OGG?
DB optimization:
* the current DB in 0.3 is quite fast but also uses a lot of memory ideas:
* keep only frequently-used fields in memory, ie. filename, title, artist,
album, albumartist, genre, tracknumber, and any other currently-displayed
columns in either collection pane or playlist view
* other fields should implement some sort of index on-disk that allows fast
searching - space used on disk is a non-issue (within reason)
* all of this should be completely transparent, requiring no change to the
Track/TrackDB external API
* memory actually seems to be less of an issue than speed, particularly on
large collections. perhaps just adding some sort of indexing to the
common fields would be best
HAL outputs:
* allow selection of device to output to via halaudiosink
* this would very neatly solve the problem of how to allow user to select
their output device
* the following HAL keys may be useful:
* sound cards have sound.* namespace and sound in info.capabilities
* sound.card_id is a string for displaying to user
* info.capabilities will contain oss.* or alsa.* namespaces for sound
devices
* alsa.type is playback on playback devices, there doesn't seem to be
an equivalent key for oss.
* .originating_device can be used to group by card
* .device_id is a string for displaying to user
* info.capabilities will have access_control and alsa/oss for mixers,
which might be a better target than the outputs themselves
* .type is mixer
* .originating_device can be used to group by card
* .device_id is a string for displaying to user
* could also allow support for multiple sound devices at once, though
at that point we would be starting to impinge on pulseaudio territory,
which is probably not ideal.
Session management:
* we should properly support x session management. the gnome implementation is
available in gnome.ui
GIO/GVFS support:
* requires patching mutagen
* would allow seamless use of music on smb/ftp/sftp shares
Misc UI ideas:
* allow arbitrary tags to be playlist columns
* minimode-like playback controls on trayicon mouseover
* replace libsexy with gtk 2.16. additionally, this would make it possible
to put a progressbar in our search box on queries that take a long time
to process.
* allow reordering of tabs in side pane and playlists
* album view like genjengel: http://gejengel.googlecode.com/svn/trunk/web/screenshots.html
Dynamic Enhancements
* Combine data from multiple sources to enhance reliability
* candidate sources:
* musicbrainz (artist)
* last.fm (track)
* rateyourmusic.com? doesnt appear to have an api and is slow...
* others?
random plugin ideas
-------------------
* jamendo
* magnatune
* ladspa plugins
* pitch/tempo adjust
|