gtkpod-devel — gtkpod development issues

Re: [Gtkpod-devel] first patch

[Sam C. <sa...@su...>]

On Sat, Aug 09, 2003 at 06:20:12PM +0200, Edward Matteucci wrote:
> Here is the first patch on gtkpod-devel.
>=20
> It's not a big feature just a little rewrite to let top25
> playlist delete the old playlist before creating the new one.
>=20
> Next to come is the iTunesDB rebuild feature (I'm working on it),

I have done something that might be similar to this, but I
don't know exectly what you want to do.

I have two new tools menu items:

- find orphaned tracks:  looks for mp3 files on the ipod
  			 that don't have an entry in the DB
			 and prompts you do delete or export=20
			 them.

- find missing tracks: 	looks for entry in the DB where the
		  	ipod_path file does not exist.  For some
			reason I had a bunch of these in my=20
			database from srewing with things :)



--=20
sam clegg
:: sa...@su... :: http://superduper.net/ :: PGP : D91EE369=20
$superduper: .signature,v 1.13 2003/06/17 10:29:24 sam Exp $

[Gtkpod-devel] Re: ipodlib...

[Sam C. <sa...@su...>]

On Sun, Aug 10, 2003 at 12:32:51AM +0900, Jorg Schuler wrote:
> I have seen ipod-on-linux.sf.net, but their code for reading the
> itunesDB was never completed (never compiled) and hasn't been touched
> for quite a long time, I think.

Yup... looks fairly dead.  They have some funny looking stuff in
there anyway (like a util to backup the ipod, written in C that
basically just does dd on the partitions)..

> It's my feeling that trying to build a library out of itunesdb.c will
> cause a lot of overhead. It seems more efficient if the program at
> hand takes care of the representation itself. itunesdb.c itself can be
> used in different programs quite easily. That's the reason why it's
> under LGPL.

There may be several arguments for not using a library but
efficiency really isn't one of them.  The overhead of using
shared objects is really really really almost unmeasurable.  If
this wasn't the case people would statically like stuff for speed=20
right?

> If you have any ideas how to make a lib without bloating the code
> speak up. Currently I use itunesdb.c to parse the iTunesDB and pass
> the information that is read to gtkpod which will build a memory
> representation. Therefore gtkpod is completely free in what it does to
> the data. Rewriting gtkpod to use an external representation of the
> data would be quite some work (and slow things down).

I see.  My only argument would be the benefit we get from sharing
code with other ipod/linux projects.=20

Regarding slow down, this depends entirely on the implementation.
If you simply compile itunesdb.c as an so without modification
you won't see *any* slowdown.  We interface can be at whatever
level we want right?

If I ever have a bunch of time I might look into this again...
but I don't right now so its all hot air.  Maybe it should go
on the TODO?

> > Also, the qahog module in gnome cvs.  Has anyone looked at this.
> Could be quite neat. I'm not using GNOME so it's difficult for me to
> check it out.

qahog have a nice little libipod already in their code which
looks really well written and clean.  You should check it out:

:pserver:ano...@an...:/cvs/gnome

module qahog

I'd say one of the biggest slowdowns with gtkpod right now is the
use of libid3.  This is a notorious library that is written in
C++ (so it forces you to link with the c++ libs) and is well
known for producing ugly slow code.  A much nicer library is libid3tag
=66rom the MAD project.  Another one for the TODO list maybe?

sam
--=20
sam clegg
:: sa...@su... :: http://superduper.net/ :: PGP : D91EE369=20
$superduper: .signature,v 1.13 2003/06/17 10:29:24 sam Exp $

[Gtkpod-devel] first patch

[Edward M. <edw...@us...>]

Here is the first patch on gtkpod-devel.

It's not a big feature just a little rewrite to let top25
playlist delete the old playlist before creating the new one.

Next to come is the iTunesDB rebuild feature (I'm working on it),

	Edward
ps apply on the latest cvs

[Gtkpod-devel] Project priorities.

[Jorg S. <Jor...@gm...>]

On Wed, Aug 06, 2003 at 01:26:53AM +0200, Edward Matteucci wrote:
> The priorities in this project could be:
> closing bugs (why does some mp3 files crash gtkpod while easytag
> isn't affected?)
> feature implementation (mp3 normalization, txt -> ipod text format
> conversion)
> ansi c compliance (I think that if we'll ever be ansi-C compliant
> there won't be any other "gcc doesn't compile" report).
> 
> We shouldn't bother about calendar and contacts as long as multisync
> does sync the iPod and many other device.

I have no objections to move along that line. Please send me _one_ of
the mp3 files that crash your computer (don't worry about the size so
long it's not more than 3-4 MB).

Cheers,


JCS.

[Gtkpod-devel] Re: normalization support and iPod

[Jorg S. <Jor...@gm...>]

Hi Edward,

(I'll send a copy to gtkpod-devel -- please subscribe and answer to there)

On Sat, Aug 09, 2003 at 12:53:00AM +0200, Edward Matteucci wrote:
> If we want to add normalization to gtkpod we should answer this question:
> how iTunes normalize the mp3 files? Is the iPod "normalization
> aware"? Does it adjust the sound volume in some way?

There's a volume adjust field in the iTunesDB for each track. I have
added support for this field (new song attribute column) and will
upload the code to CVS now. All you have to do is to set this field to
a value between -100 and +100 to adjust the volume of the
corresponding track.

> I have found that there are two ways to the normalization:
> detect volume level-->decode (mp3->wav) file-->normalize wav --> encode (wav->mp3)
Not necessary with the iPod.

> detect volume level--> add a metadata keeping the sound level

That's the way to go. "Metadata" simply is the newly supported field.

> the first strategies can be found pretty everywhere but it's:
> time consuming
> cpu&hd intensive
> not very "sound quality" friendly
> not usable on a big mp3 collection (10Gb are a big collection)
> 
> the second one is pretty fast but we should understand how the iPod
> want this tag.
> 
> I've seen a PowerBook normalize my mp3 collection on the iPod (1500 files).
> it was a long operation (around 25 minutes) but it's not even
> comparable to decoding&encoding operation.
> 
> I think that they use something similar to mp3gain based on the
> replaygain proposal.

We could try to use the mp3gain code (as you pointed out, it's under
LPGL). mp3gain is not well supported under Linux (took some effort to
compile 1.4 -- it obviously was never tested) -- so it would be
difficult to ask people to just get it as an external program (like we
do with xmms). mp3gain is slow, but quite promising.

Cheers,


JCS.

[Gtkpod-devel] ipodlib...

[Jorg S. <Jor...@gm...>]

> > > Is the mailing list working yet?  I think I subscribed but no
> > > mail yet.
> > 
> > We have gtkpod-cvs (sends updates of cvs commits) and gtkpod-devel (no
> > mails yet -- feel free to start ;-) ).
> 
> OK... here we go with a message to gtkpod-devel.

Makes me realize I hadn't even signed up myself...

> I think it would be great if there was a single libitunesdb and
> libipod that all projects could share.  
> 
> Have you seen ipod-on-linux.sf.net?  They have libraries for this
> but I don't know how uptodate they are?  Do you guys work with
> them at all.  It looks like they are trying to build in support
> for HFS plus directly which seems a little silly now that its in
> the kernel.

I have seen ipod-on-linux.sf.net, but their code for reading the
itunesDB was never completed (never compiled) and hasn't been touched
for quite a long time, I think.

It's my feeling that trying to build a library out of itunesdb.c will
cause a lot of overhead. It seems more efficient if the program at
hand takes care of the representation itself. itunesdb.c itself can be
used in different programs quite easily. That's the reason why it's
under LGPL.

Making the itunesdb.c a lib will also cause difficulties everytime a
new feature is added (I've just added the volume adjustment
feature). The "song" structure will contain another entry (volume
adjust) and the different verions of the lib are incompatible.

If you have any ideas how to make a lib without bloating the code
speak up. Currently I use itunesdb.c to parse the iTunesDB and pass
the information that is read to gtkpod which will build a memory
representation. Therefore gtkpod is completely free in what it does to
the data. Rewriting gtkpod to use an external representation of the
data would be quite some work (and slow things down).

> Also, the qahog module in gnome cvs.  Has anyone looked at this.
> They seem to use modified versions on the libraries from
> ipod-on-linux.  It lets you browse the ipod through nautilus
> although at the moment is simple seems to display all the mp3
> files in one big directory.

Could be quite neat. I'm not using GNOME so it's difficult for me to
check it out.

Cheers,


JCS.

[Gtkpod-devel] Re: partch to use g_build_filename

[Sam C. <sa...@su...>]

On Sat, Aug 09, 2003 at 06:35:16PM +0900, Jorg Schuler wrote:
> On Sat, Aug 09, 2003 at 08:29:16AM +0100, Sam Clegg wrote:
> > On Sat, Aug 09, 2003 at 02:02:49PM +0900, Jorg Schuler wrote:
>=20
> > Is the mailing list working yet?  I think I subscribed but no
> > mail yet.
>=20
> We have gtkpod-cvs (sends updates of cvs commits) and gtkpod-devel (no
> mails yet -- feel free to start ;-) ).

OK... here we go with a message to gtkpod-devel.

I think it would be great if there was a single libitunesdb and
libipod that all projects could share. =20

Have you seen ipod-on-linux.sf.net?  They have libraries for this
but I don't know how uptodate they are?  Do you guys work with
them at all.  It looks like they are trying to build in support
for HFS plus directly which seems a little silly now that its in
the kernel.

Also, the qahog module in gnome cvs.  Has anyone looked at this.
They seem to use modified versions on the libraries from
ipod-on-linux.  It lets you browse the ipod through nautilus
although at the moment is simple seems to display all the mp3
files in one big directory.

Would be great if all these project shared a common C-library
right?

OK, theres the first post to -devel!

sam
--=20
sam clegg
:: sa...@su... :: http://superduper.net/ :: PGP : D91EE369=20
$superduper: .signature,v 1.13 2003/06/17 10:29:24 sam Exp $

[Gtkpod-devel] first post!

[Sam C. <sa...@su...>]

First Post! =20
Maybe...

I this the place to send patches now?
--=20
sam clegg
:: sa...@su... :: http://superduper.net/ :: PGP : D91EE369=20
$superduper: .signature,v 1.13 2003/06/17 10:29:24 sam Exp $