I have had a look at LYR200 as EvilLyrics has a plugin Eviltagger which autotags lyrics. I would like to support as many tags as possible. Including external files. (Would they be stored like voice files?)
My thoughts on structure
A builder --> 2D aray --> Viewable by WPS
--> text file --> Viewer to view the whole file at once, it has so many view options, no need to repeat it
I plan to have this array as part of the id3entry structure see id3.h When i increase
char id3v2buf; --> char id3v2buf; That is when I get the memory problems. The sim works fine. You are suggesting that I should be able to go much greater than this.
What am I doing wrong?
I uploaded the text to viewer part as a patch. http://sourceforge.net/tracker/index.php?func=detail&atid=439120&group_id=44306&aid=1426910
I included the origional files and the diff.
The diff -u didnt seem to make the output look as others work. I just used cygwin and compared the two files locally.
Is there a way of comparing the live cvs with what I have done?
Also english.lang came up with no differences, when there was.
Bluechip <email@example.com> wrote:
And of course there are the LYR and LYR200 lyric tag styles, not to
mentioned interspersed id3v2 tags, and I wouldn't be surprised if
someone had botched lyrics into APE tags.
How about writing the lyric handler in TWO parts. One part to build
an internal 'RockLyrics' format; and another to actually display them
...this should fit your 2D array idea. But with the focus on the
code being designed so that new formats can be added. The Lyrics
will be (near): Start-of-file, interspersed, End-of-file or
seperate-file. The last group may be textual, or graphical.
I think what with the support of iPODs pretty much done, we should
consider that we have TV-Out now ...how about support the +96 .CDG
file format for true karaoke emulation? Using the Archos units as a
mixer is just a matter of tweaking a couple of DAC registers. I was
gonna write a Karaoke plugin once, but it never really got past the
design phase - so I have no code of much use to you, but the ideas
are all still there.
Forget interspersed lyrics - they will be a bitchX ...unless Occam
decides to shave again soon.
I would also not get too involved with CDG support, as that will work
very differently, as they are the only standard format I can think of
which has embedded graphics.
You ideally need the lyrics data in RAM when you are building the
RockLyrics (2D array) info.
If you are prepared to scan the master-data twice, you can simply
COUNT the first time around; and BUILD the second time around ...this
should make the limitation of a static quantity of Plugin RAM easy to
It might be worth taking a moment to infer what is a realistic
maximum amount of data you would need to hold. If you get to more
than about 12K, you may need to be careful with your code, but I
don't think it will come to that. I'm sure I remember the quote "1KB
= 1 page of text" ...even with a complex time index table - I can't
see the data ever being much bigger than about 3K per song.
Hope there's something helpful there.
>I personally dislike storing things like images and large texts in
>id3v2 tags, although it would be one more step towards implementing
>features of the original iriver firmwares (btw, is lyrics support a
>stopper for an iriver release of rockbox?).
>lrc files, which are widely available are a far better way of
>storing lyrics, and the software that puts lyrics in the id3 tags
>usually start from an lrc file.
>If lyrics are ever to be implemented, it would be a good idea to
>support both solutions.
>George Styles wrote:
>>Cool :) i would love to have Lyric support added to Rockbox...
>>of course, syncro lyrics would be perfect - not sure how they are
>>encoded in id3 though - but ideally (like you said) there would be
>>a wps tag for lyrics
Yahoo! Photos – NEW, now offering a quality print service from just 8p a photo.
Received on Wed Feb 8 10:01:43 2006