ID3v2 SYLT frame

[Marvin Schmidt-2]

Hi list, hi Lukas

I'd like to know if you're aware of
       
         https://bugs.kde.org/show_bug.cgi?id=94927#c11 
       
It links to
http://mail.kde.org/pipermail/taglib-devel/2007-July/000717.html
where i attached a implementation of the ID3v2 SYLT frame. I would
appreciate it if you could take a look at it and tell me whether it
would be possible to work that into 1.6 or if the merge-window is
already closed. :)
If it can't make it into 1.6 i would suggest sending you a proper
format-patch once TagLib is using git.

Best regards,
Marvin Schmidt

_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

On Wed, Sep 9, 2009 at 3:10 PM, Marvin Schmidt <marvin_schmidt@...> wrote:
> Hi list, hi Lukas

Hi Marvin,

> I'd like to know if you're aware of
>
>         https://bugs.kde.org/show_bug.cgi?id=94927#c11
>
> It links to
> http://mail.kde.org/pipermail/taglib-devel/2007-July/000717.html
> where i attached a implementation of the ID3v2 SYLT frame. I would
> appreciate it if you could take a look at it and tell me whether it
> would be possible to work that into 1.6 or if the merge-window is
> already closed. :)

No, I was not aware of this patch. The main reason is -- there is no
bug report for it. Lyric3 support is something I consider very low
priority, so I didn't even look at comments there. I'll review the
patch tomorrow and most likely commit to SVN, so that it's included in
1.6.

--
Lukas Lalinsky
lalinsky@...
_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

2009/9/11 Lukáš Lalinský <lalinsky@...>:

> On Wed, Sep 9, 2009 at 3:10 PM, Marvin Schmidt <marvin_schmidt@...> wrote:
>> It links to
>> http://mail.kde.org/pipermail/taglib-devel/2007-July/000717.html
>> where i attached a implementation of the ID3v2 SYLT frame. I would
>> appreciate it if you could take a look at it and tell me whether it
>> would be possible to work that into 1.6 or if the merge-window is
>> already closed. :)
>
> No, I was not aware of this patch. The main reason is -- there is no
> bug report for it. Lyric3 support is something I consider very low
> priority, so I didn't even look at comments there. I'll review the
> patch tomorrow and most likely commit to SVN, so that it's included in
> 1.6.

I took a quick look and I think it will have to wait for 2.0.
Technically it seems fine, but I disagree with the structure it's
using. The ID3 specification doesn't say anything about special
handling of newlines. It says that they are treated as any other
whitespace (at the beginning of a word). We don't have special
handling for newlines in UnsynchronizedLyricsFrame either.

[ Note that there is a bug in the handling, if you have "foo" $00 $00
$01 $0A "bar" $00 $00 $02, you will ignore the last part after $0A ]

That would reduce List< Map<long, String> > to Map<long, String>, but
the specification doesn't specifically say that timestamps are
required to be unique. I'd prefer to see it as List< Pair<long,
String> >.

There are also some minor issues, for example that
SynchronizedLyricsFrame should not have those default values in
contructor, but those are trivial to fix.

--
Lukas Lalinsky
lalinsky@...
_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel

2009/9/13 Marvin Schmidt <Thund3r@...>:

> I think it's not really important for the UnsychronizedLyricsFrame to
> handle newlines in a special manner, since the most common use case is
> getting the plain lyrics and showing them to the end-user.
> With synchronized lyrics it's more likely that you want to know what to
> display together (e.g. lines) and when of course.
> Using List< Pair<long, String> > applications would have to check to for
> newlines themselves to figure out what belongs together. I'd it's
> diserable to be able to iterate over the lines and it's syllables in
> case of lyrics. But i'm currently not sure how that fits in with other
> content types.

The problem I see with this is that the ID3 specification doesn't
mention 0x0A as a character that needs special handling. That means
it's up to applications how they use it (the same applies for spaces).
We could provide a method to transform it into the per-line
representation, but I think the data should be stored in a way that
corresponds with the ID3 specification, which says that synchronized
lyrics are a list of syllabes with timestamps.

--
Lukas Lalinsky
lalinsky@...
_______________________________________________
taglib-devel mailing list
taglib-devel@...
https://mail.kde.org/mailman/listinfo/taglib-devel