Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
Translations



Rockbox mail archive

Subject: Re[2]: godfather export

Re[2]: godfather export

From: Eric Linenberg <elinenbe_at_umich.edu>
Date: Wed, 31 Mar 2004 20:53:55 -0500

The Godfather "TGF" is a free program. Do thank the author however as
it is one of the best pieces of software out there (once you get past
the little anomalies)

-e

JW> does TGF require registration to export to a file?
JW> ----- Original Message -----
JW> From: <rockbox-request_at_cool.haxx.se>
JW> To: <rockbox_at_cool.haxx.se>
JW> Sent: Tuesday, March 30, 2004 8:55 AM
JW> Subject: Rockbox Digest, Vol 2, Issue 137


>> Send Rockbox mailing list submissions to
>> rockbox_at_cool.haxx.se
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://cool.haxx.se/mailman/listinfo/rockbox
>> or, via email, send a message with subject or body 'help' to
>> rockbox-request_at_cool.haxx.se
>>
>> You can reach the person managing the list at
>> rockbox-owner_at_cool.haxx.se
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Rockbox digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Stream Recording [Was Re: Really OT] [is now even further OT] (cb)
>> 2. Re: playlist usability issues (Bj?rn Stenberg)
>> 3. Re: Excel (Jason Williams)
>> 4. voice build change? (Daniel Stenberg)
>> 5. Re: voice build change? ([IDC]Dragon)
>> 6. Re: voice build change? (John covici)
>> 7. Re: voice build change? (Linus Nielsen Feltzing)
>> 8. Re: voice build change? (Daniel Stenberg)
>> 9. Problem between config loading and settings (John covici)
>> 10. Re: voice build change? ([IDC]Dragon)
>> 11. Re: Excel (Andreas Stemmer)
>> 12. Re: voice build change? (Daniel Stenberg)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 30 Mar 2004 12:14:20 +0100
>> From: cb <c-l-b_at_usa.net>
>> Subject: Stream Recording [Was Re: Really OT] [is now even further OT]
>> To: <rockbox_at_cool.haxx.se>
>> Message-ID: <525icdLou1232S13.1080645260_at_uwdvg013.cms.usa.net>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> The forum for stream recording is
>>
>> http://pub25.ezboard.com/bstreemeboxvcr
>>
>> I suggest you start with their FAQ
>>
>> StreamboxVCR is long dead. Its sucessor is called net transport
>> http://www.xi-soft.com/
>> you CAN get it to schedule live stream recording
>>
>> The FAQ lists all of the software that will record directly (ala VCR)
>> http://pub25.ezboard.com/fstreemeboxvcrfrm7.showMessage?topicID=1.topic
>>
>> and indirectly (ala TotalRecorder)
>> http://pub25.ezboard.com/fstreemeboxvcrfrm7.showMessage?topicID=11.topic
>>
>> cb
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 30 Mar 2004 13:19:28 +0200
>> From: Bj?rn Stenberg <bjorn_at_haxx.se>
>> Subject: Re: playlist usability issues
>> To: Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <20040330111928.GA14396_at_linux3.contactor.se>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> Leif Sawyer wrote:
>> > After a party this weekend, and hitting this issues quite a few times
>> > due to .. um.. improper application of alcohol and MP3 queueing.. I'm
>> > inclined to agree with Isaac.
>> >
>> > Once it's been established that we're in a playlist-generation mode,
JW> while
>> > we're in the browse-mode, 'play/pause' should act as 'insert->last' so
JW> that
>> > it's a very quick way to add music to the end of the playlist, and won't
>> > accidently erase your hard work.
>>
>> I call this "party mode":
>>
>>
>> http://rockbox.haxx.se/mail/archive/rockbox-archive-2003-09/0310.shtml
>>
>> --
>> Björn
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 30 Mar 2004 05:52:32 -0600
>> From: "Jason Williams" <jwilliams_at_wi.rr.com>
>> Subject: Re: Excel
>> To: <rockbox_at_cool.haxx.se>
>> Message-ID: <002e01c4164d$7c8c0320$6401a8c0_at_Laptop>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Does any one know how to get ID3 information out of mp3's from VB? Or
>> alternatively, is there a program that will dump all ID3 info to a file?
>>
>> TIA
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 30 Mar 2004 13:47:12 +0200 (CEST)
>> From: Daniel Stenberg <daniel_at_haxx.se>
>> Subject: voice build change?
>> To: Rockbox <rockbox_at_cool.haxx.se>
>> Message-ID: <Pine.LNX.4.58.0403301343010.4501_at_linux3.contactor.se>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi
>>
>> I just now realized that the voice stuff adds a whole bunch of blank
JW> strings
>> to lang.c without any really good reason.
>>
>> I therefor suggest that we move the voice-only strings from the lang.[ch]
>> files into a separate lang-voice.h file.
>>
>> Attached to this mail is my suggested gelang patch that makes it generate
JW> such
>> a lang-voice.h file. All it takes is for two .c files to include this and
>> we're working fine again without blank stings in lang.c (and thus in all
>> binary language files as well).
>>
>> genlang checks the 'desc' field in the .lang file for the magic string
JW> 'spoken
>> only' to detect voice-only strings.
>>
>> Comments?
>>
>> --
>> Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/
>> -------------- next part --------------
>> Index: genlang
>> ===================================================================
>> RCS file: /cvsroot/rockbox/tools/genlang,v
>> retrieving revision 1.11
>> diff -u -r1.11 genlang
>> --- genlang 31 Jan 2003 09:04:34 -0000 1.11
>> +++ genlang 30 Mar 2004 11:34:00 -0000
>> _at__at_ -20,6 +20,7 _at__at_
>>
>> open(HFILE, ">$prefix.h");
>> open(CFILE, ">$prefix.c");
>> +open(VFILE, ">${prefix}-voice.h");
>>
>> print HFILE <<MOO
>> /* This file was automaticly generated using genlang */
>> _at__at_ -46,6 +47,13 _at__at_
>> MOO
>> ;
>>
>> +print VFILE <<MOO
>> +/* This file was automaticly generated using genlang.
>> + The enum below contains all available voice strings */
>> +enum {
>> +MOO
>> + ;
>> +
>> open(LANG, "<$input");
>> while(<LANG>) {
>> $line++;
>> _at__at_ -75,9 +83,13 _at__at_
>> # if not set, get the english version
>> $value = $set{'eng'};
>> }
>> -
>> - print HFILE " ".$set{'id'}.",\n";
>> - print CFILE " $value,\n";
>> + if($set{'desc'} !~ /spoken only/i) {
>> + print HFILE " ".$set{'id'}.",\n";
>> + print CFILE " $value,\n";
>> + }
>> + else {
>> + print VFILE " ".$set{'id'}.",\n";
>> + }
>>
>> undef %set;
>> }
>> _at__at_ -95,6 +107,13 _at__at_
>> MOO
>> ;
>>
>> +print VFILE <<MOO
>> + VOICE_LAST_INDEX_IN_ARRAY /* this is not a voice, this is a marker */
>> +};
>> +/* end of generated enum list */
>> +MOO
>> + ;
>> +
>> print CFILE <<MOO
>> };
>> /* end of generated string list */
>> _at__at_ -103,5 +122,6 _at__at_
>>
>> close(CFILE);
>> close(HFILE);
>> +close(VFILE);
>>
>> exit $errors;
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Tue, 30 Mar 2004 14:25:29 +0200 (MEST)
>> From: "[IDC]Dragon" <idc-dragon_at_gmx.de>
>> Subject: Re: voice build change?
>> To: Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <28871.1080649529_at_www53.gmx.net>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> >I just now realized that the voice stuff adds a whole bunch of blank
>> strings
>> >to lang.c without any really good reason.
>>
>> Yes, I am aware of this since I started it. We're wasting 5 bytes per
>> voice-only ID, 4 for the pointer, 1 for the null char it points to. I
JW> talked to
>> Linus about it, he wasn't concerned. But agreed, I also don't like it.
>>
>> >I therefor suggest that we move the voice-only strings from the lang.[ch]
>> >files into a separate lang-voice.h file.
>>
>> It's very beneficial for the voice code to have one set of IDs, not two. I
>> was thinking about assigning negative IDs to the voice-only ones. So they
>> could appear in the lang.h enum, but not in the lang.c array. I need
JW> something
>> that can grow in 2 directions, such that an older voicefile with newer
JW> software
>> does not get all entries shifted. (That would make it really difficult to
>> use ;-)
>>
>> >genlang checks the 'desc' field in the .lang file for the magic string
>> 'spoken
>> >only' to detect voice-only strings.
>>
>> Uh, why that? Spoken-only are those which have an empty "regular" text
>> field.
>>
>>
>> Jörg
>>
>> --
>> +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz
JW> +++
>> 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Tue, 30 Mar 2004 07:31:57 -0500
>> From: John covici <covici_at_ccs.covici.com>
>> Subject: Re: voice build change?
>> To: Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <16489.26813.682054.730896_at_ccs.covici.com>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> Maybe it will take up a few more bytes on the computer, but for us
>> humans it will be much easier to maintain if you keep it the way it
>> is. Unless things get very large of course, but you don't have to
>> worry about this for a while, I think.
>>
>> on Tuesday 03/30/2004 [IDC]Dragon(idc-dragon_at_gmx.de) wrote
>> > >I just now realized that the voice stuff adds a whole bunch of blank
>> > strings
>> > >to lang.c without any really good reason.
>> >
>> > Yes, I am aware of this since I started it. We're wasting 5 bytes per
>> > voice-only ID, 4 for the pointer, 1 for the null char it points to. I
JW> talked to
>> > Linus about it, he wasn't concerned. But agreed, I also don't like it.
>> >
>> > >I therefor suggest that we move the voice-only strings from the
JW> lang.[ch]
>> > >files into a separate lang-voice.h file.
>> >
>> > It's very beneficial for the voice code to have one set of IDs, not
JW> two. I
>> > was thinking about assigning negative IDs to the voice-only ones. So
JW> they
>> > could appear in the lang.h enum, but not in the lang.c array. I need
JW> something
>> > that can grow in 2 directions, such that an older voicefile with newer
JW> software
>> > does not get all entries shifted. (That would make it really difficult
JW> to
>> > use ;-)
>> >
>> > >genlang checks the 'desc' field in the .lang file for the magic string
>> > 'spoken
>> > >only' to detect voice-only strings.
>> >
>> > Uh, why that? Spoken-only are those which have an empty "regular" text
>> > field.
>> >
>> >
>> > Jörg
>> >
>> > --
>> > +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz
JW> +++
>> > 100% Virenerkennung nach Wildlist. Infos:
JW> http://www.gmx.net/virenschutz
>> >
>> > _______________________________________________
>> > http://cool.haxx.se/mailman/listinfo/rockbox
>>
>> --
>> John Covici
>> covici_at_ccs.covici.com
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Tue, 30 Mar 2004 14:38:58 +0200
>> From: Linus Nielsen Feltzing <linus_at_haxx.se>
>> Subject: Re: voice build change?
>> To: covici_at_ccs.covici.com, Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <40696A62.8010403_at_haxx.se>
>> Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>> John covici wrote:
>> > Maybe it will take up a few more bytes on the computer, but for us
>> > humans it will be much easier to maintain if you keep it the way it
>> > is.
>>
>> Humans are not supposed to edit the lang.[ch] files. They are generated
>> by the genlang script. The .lang files are not affected by this change.
>>
>> Linus
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Tue, 30 Mar 2004 14:48:18 +0200 (CEST)
>> From: Daniel Stenberg <daniel_at_haxx.se>
>> Subject: Re: voice build change?
>> To: Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <Pine.LNX.4.58.0403301442320.22051_at_linux3.contactor.se>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>>
>> On Tue, 30 Mar 2004, [IDC]Dragon wrote:
>>
>> > It's very beneficial for the voice code to have one set of IDs, not two.
JW> I
>> > was thinking about assigning negative IDs to the voice-only ones. So
JW> they
>> > could appear in the lang.h enum, but not in the lang.c array.
>>
>> Since we access language strings with "array[index]" everything that makes
JW> us
>> increase the index without actually storing a useful string there is
JW> wasteful.
>>
>> I don't see how we can have them in the same array without wasting
JW> strings.
>>
>> > I need something that can grow in 2 directions, such that an older
JW> voicefile
>> > with newer software does not get all entries shifted. (That would make
JW> it
>> > really difficult to use ;-)
>>
>> It won't get shifted unless you remove voice entries, and you mustn't
JW> remove
>> entries without chaning the voice file number, in the exact same manner
JW> the
>> binary languages work. You don't remove language ids either.
>>
>> > >genlang checks the 'desc' field in the .lang file for the magic string
>> > 'spoken
>> > >only' to detect voice-only strings.
>> >
>> > Uh, why that? Spoken-only are those which have an empty "regular" text
>> > field.
>>
>> No. Empty text fields in the .lang file is how we deprecate ordinary
JW> language
>> strings. We can't assume that deprecated strings should be spoken! ;-)
>>
>> I chose the 'spoken only' string since you had already used that on all
>> strings that are spoken only and I didn't want to add any extra
JW> control-option
>> to the file.
>>
>> --
>> Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/
>>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Tue, 30 Mar 2004 08:03:32 -0500
>> From: John covici <covici_at_ccs.covici.com>
>> Subject: Problem between config loading and settings
>> To: Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <16489.28709.219023.523157_at_ccs.covici.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> I am getting some strange behavior when loading a config as opposed
>> to the actual settings.
>>
>> Timesplit is always deleted and settings loaded is no longer voiced.
>> Also, directories are always spoken as numbers even if the correct
>> entry is in the .cfg file.
>>
>> Thanks.
>>
>> --
>> John Covici
>> covici_at_ccs.covici.com
>>
>>
>> ------------------------------
>>
>> Message: 10
>> Date: Tue, 30 Mar 2004 15:43:32 +0200 (MEST)
>> From: "[IDC]Dragon" <idc-dragon_at_gmx.de>
>> Subject: Re: voice build change?
>> To: Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <11803.1080654212_at_www53.gmx.net>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> > > It's very beneficial for the voice code to have one set of IDs, not
JW> two.
>> > > I
>> > > was thinking about assigning negative IDs to the voice-only ones. So
>> > > they
>> > > could appear in the lang.h enum, but not in the lang.c array.
>> >
>> > Since we access language strings with "array[index]" everything that
JW> makes
>> > us
>> > increase the index without actually storing a useful string there is
>> > wasteful.
>> >
>> > I don't see how we can have them in the same array without wasting
>> > strings.
>>
>> Again, by assigning negative values to them in the enum, growing further
>> into the negative range.
>>
>> > > I need something that can grow in 2 directions, such that an older
>> > > voicefile
>> > > with newer software does not get all entries shifted. (That would make
>> > > it
>> > > really difficult to use ;-)
>> >
>> > It won't get shifted unless you remove voice entries, and you mustn't
>> > remove
>> > entries without chaning the voice file number, in the exact same manner
>> > the
>> > binary languages work. You don't remove language ids either.
>>
>> OK. But still I have that problem with 2 sets, one for potentially voiced
>> strings, another for voice only entries. I'd need to introduce a second
JW> talk
>> function, e.g. talk_string() and talk_voice() instead of just talk_id(). I
JW> need
>> to know in advance which to call, the freedom gets lost. The voice file
>> needs two "directories", currently it has one.
>> Or the voice-only IDs have to get bumped into a completely different
JW> range,
>> this is where I suggest the negative. So I could still feed this into the
>> same function. Hmm, it just appeared to me that negative is not so good
JW> either,
>> because I use the upper bits of the ID to indicate numbers and units, with
>> the value in the lower bits. Very useful for option entries with numbers,
JW> so I
>> still need only one ID to speak the full thing. (Are you with me?)
>> I could modify this to not use the MSB, so negative is free.
>>
>> > > >genlang checks the 'desc' field in the .lang file for the magic
JW> string
>> > > 'spoken
>> > > >only' to detect voice-only strings.
>> > >
>> > > Uh, why that? Spoken-only are those which have an empty "regular" text
>> > > field.
>> >
>> > No. Empty text fields in the .lang file is how we deprecate ordinary
>> > language
>> > strings. We can't assume that deprecated strings should be spoken! ;-)
>>
>> Well, then empty their voice content, too.
>> In other words: a voice-only entry is one which has empty text, but a
JW> voice
>> content.
>>
>> > I chose the 'spoken only' string since you had already used that on all
>> > strings that are spoken only and I didn't want to add any extra
>> > control-option
>> > to the file.
>>
>> Certainly. I just won't rely on comments. If you don't want to check the
>> content, you could distinguish because I named them VOICE_xx instead of
JW> LANG_xx.
>>
>> Jörg
>>
>> --
>> +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz
JW> +++
>> 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
>>
>>
>>
>> ------------------------------
>>
>> Message: 11
>> Date: Tue, 30 Mar 2004 16:43:08 +0200
>> From: Andreas Stemmer <groovingandi_at_gmx.de>
>> Subject: Re: Excel
>> To: Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <1080657788.680.7.camel_at_andi212>
>> Content-Type: text/plain
>>
>> Jason Williams wrote:
>> > Does any one know how to get ID3 information out of mp3's from VB? Or
>> > alternatively, is there a program that will dump all ID3 info to a file?
>>
>> IIRC mp3TagStudio is able to export all id3 info to excel or html, as
>> well as TheGodFather or MP3BookHelper
>>
>> http://rockbox.haxx.se/docs/tools.html
>>
>> I'm sure a few other tools from the tools page that I didn't mention
>> above are also able to do it, but I didn't test all of them.
>>
>> Andreas
>>
>>
>>
>> ------------------------------
>>
>> Message: 12
>> Date: Tue, 30 Mar 2004 16:52:14 +0200 (CEST)
>> From: Daniel Stenberg <daniel_at_haxx.se>
>> Subject: Re: voice build change?
>> To: Rockbox development <rockbox_at_cool.haxx.se>
>> Message-ID: <Pine.LNX.4.58.0403301643590.22051_at_linux3.contactor.se>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>>
>> On Tue, 30 Mar 2004, [IDC]Dragon wrote:
>>
>> > > I don't see how we can have them in the same array without wasting
>> > > strings.
>> >
>> > Again, by assigning negative values to them in the enum, growing further
>> > into the negative range.
>>
>> Yes, that would work. We could also just OR 0x8000 or something suitably
JW> large
>> to make them end up in a different range of values.
>>
>> Either way, the fact that it is negative or has 0x8000 set could be used
JW> to
>> determine if it is a voice-only string.
>>
>> > OK. But still I have that problem with 2 sets, one for potentially
JW> voiced
>> > strings, another for voice only entries.
>>
>> Right, we can't have it that way. We need to have unique identifiers for
JW> each
>> voice string.
>>
>> > Hmm, it just appeared to me that negative is not so good either, because
JW> I
>> > use the upper bits of the ID to indicate numbers and units, with the
JW> value
>> > in the lower bits. Very useful for option entries with numbers, so I
JW> still
>> > need only one ID to speak the full thing. (Are you with me?) I could
JW> modify
>> > this to not use the MSB, so negative is free.
>>
>> We could easily make them start at 0x1000 or so instead if that makes it
JW> less
>> intrusive on the existing code.
>>
>> > Well, then empty their voice content, too. In other words: a voice-only
>> > entry is one which has empty text, but a voice content.
>>
>> True. I'll go with that.
>>
>> --
>> Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Rockbox mailing list
>> Rockbox_at_cool.haxx.se
>> http://cool.haxx.se/mailman/listinfo/rockbox
>>
>>
>> End of Rockbox Digest, Vol 2, Issue 137
>> ***************************************


JW> _______________________________________________
JW> http://cool.haxx.se/mailman/listinfo/rockbox

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2004-04-01

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy