Intone and lyrics with album art;)

[Laszlo KREKACS]

On Wed, Sep 2, 2009 at 4:36 PM, c_c<cchandel at yahoo.com> wrote:
>
> Hi,
>  Let me first thank you for taking the time to suggest improvements to this
> part of intone. I was getting the feeling that maybe people hardly used
> these features - particularly the lyrics view.

No problem. I was always dreaming of a device what can do proper lyrics
and a dictionary app. So the lyrics is there I only need to write a dict app;-)


>  Well, that is a limitation. I was working on the concept that the songs
> would be organised in directories by album - so the cover art would remain
> the same for all songs in a directory.

I asked you some time back (about a month) how to do flashcard type reading.
It was suggested that I should put a .jpg file for the musics....

In that usecase (when I have 100-200 .mp3s) its really cumbersome to
put each file its own directory.

>  For a directory filled with mixed songs - I will need to get the album
> name from the tags (if the file is tagged) and then look for the album art
> in some predefined directory based on the tag. Seemed like a lot of work to
> do at that time :-)

No, its too complicated. I would like to see an implementation like this:
Search for a .jpg identical to the filename. If it fails search for
cover.jpg, if it
fails display the default head icon.

It is dead simple and would cover all usecases. If somebody want an
album support,
then put the effort and separate his mp3 files into different dir.


>  I'll try and do something like the above when I find some free time.

Please implement the more simple approach.

>  That it is. Unfortunately, hidden widgets in elementary still occupy
> space. Hence I need to delete them, and then add them again when needed. If
> you find a better way - do let me know.
>  I can read the next file into a large buffer and copy from there on song
> change. But that might play up with the memory. I'll try that and see how it
> goes.


Ok, as elementary widgets are evas object anyway, they are placed in
layers on evas canvas.

By default every elementary widget is placed to layer 0. You only need
to place the same sized entry widget on top of the existing one.
And show/hide only means you manipulate the layering.

In python it would something like this:

en = elementary.Entry(win)
en2 = elementary.Entry(win)
layer = en.layer_get()
layer2 = en.layer_get()

#place en2 on top of en:
en2.layer_set(1)
en.layer_set(0)

#place en on top of en2:
en2.layer_set(0)
en.layer_set(1)

To make a second textbox look like the first one,
you should set its properties (x,y, width, height)
the same what the other Entry has.
Functions:
x,y = en.pos_get()
en2.pos_set(x,y)
width, height = en.size_get()
en2.size_set(width, height)

Hope it helps something.


>> 2. Entry does not wrap lines
>> 3. Entry does not scroll at the beginning when it loads a new entry text
>> 4. The scrollbar is disabled
>> 5. Disable horizontal scrolling
>>
>  Done. Try the attached binary below.

Thank you! I will try it this evening.

>  Well, I like the idea and am willing to implement it. Only - are there
> lyrics files available in the subtitle formats? And which format do I
> support? I can use either the .srt/.sub/mplayer formats.
>  Thanks for the suggestions and ideas though.

To say the true, we should look for subtitle for a release,
because it can has offset, or wrong framerate.
So I think most of the times (random music with third
party subtitle file) we want to adjust the subtitle file anyway.

So I would propose to have a minimal timing gui for it.

You display one line at a time, and when I tap on the screen, it
autofills the timing in the file. It would work most of the time.

For format selection:
No matter what you choose (.srt/.sub/mplayer), because we can
convert them to each other.
If I were you I would prefer .srt file format, because it is time based
(and not frame based). For additional info please see:
http://en.wikipedia.org/wiki/SubRip

With this my needs would suffice. However I dont know if it would be
enough to proper karaoke support. For karaoke we need to
highlight *part of the actual word*, ie. some chars from the line.

Yes we can implement it via some custom way (using semi html markup
and display the same line many times highlighting other part of the line).

But maybe a proper karaoke fileformat would be needed.
I think the best would be matroska fileformat:
http://www.matroska.org/technical/specs/subtitles/ssa.html

It can do many advanced thing, including highlight the part of the word.

But it is a *HUGE* work, so I think we should implement subrip first, and
gather some experience, and tackle the more advanced usecase (ie. karaoke)
next.


Many thanks for your positive comments by the way!

Best regards,
 Laszlo