From: Michael T. <ti...@ti...> - 2007-06-24 19:06:53
|
I've completed an initial release of the code to add gapless track data for files encoded with a LAME tag. The values have been verified to match what iTunes uses for identical files and to work as well on the ipod as iTunes uploaded files do. The updated files (mp3file.c and mp3file.h) can be downloaded from http://www.tiffman.com/gtkpod/ as well as some sample files to test gapless playback. Only newly added files are currently scanned; I tried to add it to the "update tracks from file" function, but it seems that since the file hash hasn't changed, the "changed" flag isn't being set. I'm sure this can be hashed out as we go forward. Some notes: Gapless playback on the ipod is finicky. Only certain models even support it (v5 and new nano, I believe). Even on the proper model, it doesn't always work 100%. Seeking in a track can cause problems; for best results, listen to a track all the way through. When the LAME tag doesn't exist, iTunes does not calculate the exact proper values. The pregap+postgap appears to be correct, but each is wrong. Some of the files still play back pretty well, but some are horrendous (192 cbr is awful). Given that, I think that we really want to just support files with the proper data already in them and not try to go too far beyond that for now. I encoded some sample files using several lame presets, and noticed that true CBR files don't seem to play back gaplessly on the ipod. iTunes calculates one of the fields (apparently) wrong, and my code simulates the wrong calculation. Even with the "correct" numbers, the ipod doesn't play it gaplessly, either with gtkpod or iTunes calculating and storing the values. I'll play around some more and see if I can determine numbers that will work. The good news is that very few files should currently get encoded CBR, except for --preset insane, which is 320 kbps CBR. I used some sample files downloaded from http://wiki.hydrogenaudio.org/index.php?title=Gapless you can use as a quick test. The original files are in gapless_WAVPACK_free_of_right.zip at the above tiffman.com url. It's a series of 17 ~5 second segments from a Beethoven composition. I took those files, unpacked them, and encoded them using various lame presets (insane, extreme, standard, 192 abr, 192 cbr) and faac (m4a), which can also be downloaded from http://www.tiffman.com/gtkpod/. They are all tagged with the genre "gapless linux" and with an artist matching the encoding setting for easier ipod navigation (just go through the genre). If you put one set on the ipod with gtkpod without my updates, you'll easily hear the gaps between tracks. Then remove, recompile, and readd for beautiful gapless playback. The m4a files don't work yet; I intend to look at that file format soon, and see what I can figure out. Also, 192 (cbr) and insane don't work, based on the above paragraph, though they are being written with the same values iTunes uses. standard, extreme, and 192abr all work just fine. Anyone who can try this out and give me some feedback would be appreciated. After I've got some confirmation that it works for other people, we can figure out how to get it into svn. Then it can be added to the gui and we can put in an option to scan existing ipod files for gapless data. Any comments/questions, let me know. Thanks, Michael -- Michael Tiffany ti...@ti... http://www.tiffman.com |
From: Tino K. <tin...@gm...> - 2007-06-24 20:39:58
|
On Sun, Jun 24, 2007 at 14:06:46 -0500, Michael Tiffany wrote: [...] > Anyone who can try this out and give me some feedback would be > appreciated. After I've got some confirmation that it works for other > people, we can figure out how to get it into svn. Then it can be added > to the gui and we can put in an option to scan existing ipod files for > gapless data. I just tested it with 2 albums. Works like a dream, thanks for that! > Any comments/questions, let me know. Now that complete albums can be played gapless, an "album gain" would be a nice feature. With this, it would be possible to normalize the volume of all tracks on the iPod, but generate the same volume gain value for all tracks that belong to the same album. Regards, Tino |
From: Jorg S. <Jor...@gm...> - 2007-06-25 00:49:18
Attachments:
mp3file.c.diff
mp3file.h.diff
|
Michael Tiffany wrote: > I've completed an initial release of the code to add gapless track data > for files encoded with a LAME tag. The values have been verified to > match what iTunes uses for identical files and to work as well on the > ipod as iTunes uploaded files do. The updated files (mp3file.c and > mp3file.h) can be downloaded from http://www.tiffman.com/gtkpod/ as well I'll try this tonight -- just a note: it's better to submit a patch against svn (which can be created by 'svn diff'), because the entire filed mp3file.c becomes useless as soon as someone else works on the original file. I've attached the corresponding diffs. Cheers, JCS. |
From: Todd Z. <tm...@po...> - 2007-06-25 04:07:57
Attachments:
gtkpod-gapless-mp3.diff
|
Michael Tiffany wrote: > I've completed an initial release of the code to add gapless track > data for files encoded with a LAME tag. Thank you Michael! I have more than a few albums that will benefit from your effort. :) > Only newly added files are currently scanned; I tried to add it to > the "update tracks from file" function, but it seems that since the > file hash hasn't changed, the "changed" flag isn't being set. I'm > sure this can be hashed out as we go forward. I took a stab at getting this to work. Jorg and others can comment on how well or how poorly I've done. Basically, I set etr->tchanged in mp3_read_gapless if track->gapless_data != gd.gapless_data. I updated file.c (update_track_from_file) to check if tchanged is set and to mark the itdb as changed if it is. Attached is a patch against current svn (all of your changes included, much as Jorg sent). I added a new album and the values were set properly. I also updated a few albums and the gapless data was updated there as well. I did find some tracks that don't update properly. Poking a bit it seems that get_header() fails for these tracks. They were encoded with Lame 3.96r (which should translate to 3.96.1). eyeD3 reads the lame tags just fine, as does madplay (-v -T). madplay does report an error when playing the file (even though it plays fine). The error is: "error: frame 0: lost synchronization." I haven't looked in the madplay source yet to see what might be causing that message. I've put one of the offending files online in case someone wants to debug a little: http://www.dmsi.cc/~tmz/10-take_the_veil_cerpin_taxt.mp3 It would just happen to be one of the larger files from the album at 17MB. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nothing is so simple that it cannot be misunderstood. -- Teague's Paradox |
From: Michael T. <ti...@ti...> - 2007-06-25 05:38:53
Attachments:
gtkpod-gapless-mp3-2.diff
|
On Mon, 2007-06-25 at 00:07 -0400, Todd Zullinger wrote: > Thank you Michael! I have more than a few albums that will benefit > from your effort. :) That's what got me interested in the first place: too many live albums, bootlegs, and progressive-y albums with multi-track songs and whatnot. :) > I did find some tracks that don't update properly. Poking a bit it > seems that get_header() fails for these tracks. They were encoded > with Lame 3.96r (which should translate to 3.96.1). eyeD3 reads the > lame tags just fine, as does madplay (-v -T). madplay does report an > error when playing the file (even though it plays fine). The error > is: "error: frame 0: lost synchronization." I haven't looked in the > madplay source yet to see what might be causing that message. manpage says "If encountered at the beginning of a file, this means the file contains something other than an ID3v2 tag before the MPEG audio data." > I've put one of the offending files online in case someone wants to > debug a little: > > http://www.dmsi.cc/~tmz/10-take_the_veil_cerpin_taxt.mp3 > > It would just happen to be one of the larger files from the album at > 17MB. :) For this file at least, the ID3 header is 10 bytes longer than it should be, so the frame header's not where I (or madplay) think it should be. Not sure why (my guess is that the ID3 extended header was meant to have been written and the flag set, but not sure), but attached is a patch encompassing your and my changes which should fix it. If you (or anyone) have any files that aren't fixed by this patch, post them and I'll give them a look. Michael -- Michael Tiffany ti...@ti... http://www.tiffman.com |
From: Nicholas P. <nic...@ni...> - 2007-06-26 18:28:49
Attachments:
libgpod-python-introspect-proxied-attributes.diff
|
Todd, On Mon, 25 Jun 2007, Todd Zullinger wrote: > Michael Tiffany wrote: > > I've been using a hacked-up version of gnupod's tunes2pod.pl to > > convert my iTunesDB to xml and looking in there. The current > > release doesn't print the gapless fields, and CVS doesn't seem to > > support it either. I can send out my iTunesDB.pm file if anyone > > cares to use it to read the gapless fields. > That'd probably be useful to have in the archives (if they don't > mangle it too badly). > This can also be done using the libgpod python bindings (with a little > modification to them...). The attached patch syncs up the available > track data with what's currently available in libgpod. Nick, is there > any reason not to apply this? (Or better yet, is there a good way to > keep this automatically up to date as fields are added in libgpod?) Try the attached patch and see what you think. Nick -- Nick Piper, Developer, LogicaCMG http://www.nickpiper.co.uk/ GPG Encrypted mail welcome! 1024D/3ED8B27F Choose life. Be Vegan :-) Please reduce needless cruelty & suffering ! |
From: Michael T. <ti...@ti...> - 2007-06-28 01:26:49
|
On Tue, 2007-06-26 at 00:43 +0900, Jorg Schuler wrote: > Thanks Michael, thanks Todd for your great work. I've gone through the > patch and did some minor changes to the "update from track" > functionality, ironing out some pre-existing (i.e. old) bugs along the way. > > I would be grateful if someone could test this patch before submitting > to SVN -- I'm not exactly into "gapless" :-/ Well, I found an instance where this probably does something we don't want it to, though it won't affect very many people at this point. If somebody already has gapless information in their iTunesDB (presumably from iTunes) for a non-lame file, and then updates from file, gapless information will not be found, it will be flagged as a change, and the previous gapless information will be removed. I attached a patch to file.c to check whether the new gapless information exists or is 0's, and only updates if it's valid information. At least for now, I assume we don't want to be overwriting any pre-existing data. The patch could really be simplified to just checking to see if the new gapless_track_flag is true. It maybe should be done this way because if we get mp4 gapless working, it has a gapless_data of 0 anyway, so the flag is the easiest/best way to know. Any comments either way, then I'll put this patch in the trunk and continue work on cleaning up mp3file in the gapless_playback branch. Michael -- Michael Tiffany ti...@ti... http://www.tiffman.com |
From: Tino K. <tin...@gm...> - 2007-06-25 20:23:20
|
On Mon, Jun 25, 2007 at 16:20:12 -0400, Todd Zullinger wrote: > Tino Keitel wrote: > > as we are talking about iTunes, how about reading the gapless infos > > back from the iTunesDB on the iPod? > > It should already be read as part of the iTunesDB parsing via libgpod. > Once a UI is added to gtkpod to expose this in some way, that will > hopefully prove correct. :) I once fed my iPod to a "real" iTunes, and it analyzed the tracks on the iPod and added gapless information. However, all coverart was lost. Then I used it again with gtkpod and did some things to bring the coverart back, and the gapless information was lost. Regards, Tino |
From: Todd Z. <tm...@po...> - 2007-06-25 20:34:04
Attachments:
libgpod-python-track-info.diff
|
Michael Tiffany wrote: >>> Can you enable that in iTunes for a track and see which of the two >>> gapless_*_flags it sets? >> >> How can I check this? > > I've been using a hacked-up version of gnupod's tunes2pod.pl to > convert my iTunesDB to xml and looking in there. The current > release doesn't print the gapless fields, and CVS doesn't seem to > support it either. I can send out my iTunesDB.pm file if anyone > cares to use it to read the gapless fields. That'd probably be useful to have in the archives (if they don't mangle it too badly). This can also be done using the libgpod python bindings (with a little modification to them...). The attached patch syncs up the available track data with what's currently available in libgpod. Nick, is there any reason not to apply this? (Or better yet, is there a good way to keep this automatically up to date as fields are added in libgpod?) With that patch, I've been checking the gapless data from an interactive python session like this: import gpod db = gpod.Database('/media/IPOD') album = [t for t in db if t['album'] and t['album'].startswith("Arizona Bay")] for track in album: print track for k in ['pregap', 'postgap', 'samplecount', 'gapless_data']: print '\t%s: %s' % (k, track[k]) That can easily be extended to print out the values for the whole database: import gpod db = gpod.Database('/media/IPOD') for track in db: print track for k in ['pregap', 'postgap', 'samplecount', 'gapless_data']: print '\t%s: %s' % (k, track[k]) Drop this in a file with '#!/usr/bin/env python' at the top, make it executable, and you can run it directly from a terminal. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But I have grown older, and you have grown colder. And nothing is very much fun, anymore. |
From: Todd Z. <tm...@po...> - 2007-06-25 20:39:29
|
Tino Keitel wrote: > I once fed my iPod to a "real" iTunes, and it analyzed the tracks on > the iPod and added gapless information. However, all coverart was > lost. Ugh. Is that because the cover art was stored separately from the files? I don't think iTunes likes cover art unless it's embedded in the file (as an APIC tag for mp3's). I don't use iTunes myself, other than to look at to help my dad and friends, but I think I've noticed this when I imported some of my own tracks to iTunes. > Then I used it again with gtkpod and did some things to bring the > coverart back, and the gapless information was lost. Hmmm. I didn't think that should happen. Until Michael's work, nothing in gtkpod should have touched those fields in the database, so I'd have expected them to remain as they were from iTunes. Maybe as part of testing the new code you would be willing to try this again sometime and see if it still happens? (Not necessarily right now, but as the feature gets integrated more.) --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An optimist believes we live in the best of all possible worlds. A pessimist is sure of it! |
From: Michael T. <ti...@ti...> - 2007-06-25 20:50:09
|
> Tino Keitel wrote: >> I once fed my iPod to a "real" iTunes, and it analyzed the tracks on >> the iPod and added gapless information. However, all coverart was >> lost. > > Ugh. Is that because the cover art was stored separately from the > files? I don't think iTunes likes cover art unless it's embedded in > the file (as an APIC tag for mp3's). I don't use iTunes myself, other > than to look at to help my dad and friends, but I think I've noticed > this when I imported some of my own tracks to iTunes. > >> Then I used it again with gtkpod and did some things to bring the >> coverart back, and the gapless information was lost. > > Hmmm. I didn't think that should happen. Until Michael's work, > nothing in gtkpod should have touched those fields in the database, so > I'd have expected them to remain as they were from iTunes. Maybe as > part of testing the new code you would be willing to try this again > sometime and see if it still happens? (Not necessarily right now, but > as the feature gets integrated more.) I lost my coverart when iTunes added its gapless information as well. All of my coverart is in separate files (front.jpg). My art still showed up for each track in gtkpod, but didn't display on the ipod. I presume one of the flags (has_artwork, maybe?) got broken by iTunes. I had to actually remove all of my art in gtkpod and re-add it (set it to not read art from files, update all from tracks, sync, read art from files, update all, sync) before I could see it again on the ipod. I believe I have saved copies of my iTunesDB from before and after, so when I get a chance, I'll see if I can tell what happened. If it's just that flag, maybe we can add some code to gtkpod make sure it's set right if a track has associated artwork. Michael -- Michael Tiffany ti...@ti... http://www.tiffman.com |
From: Michael T. <ti...@ti...> - 2007-06-25 22:00:48
|
> I lost my coverart when iTunes added its gapless information as well. All > of my coverart is in separate files (front.jpg). My art still showed up > for each track in gtkpod, but didn't display on the ipod. I presume one > of the flags (has_artwork, maybe?) got broken by iTunes. I had to > actually remove all of my art in gtkpod and re-add it (set it to not read > art from files, update all from tracks, sync, read art from files, update > all, sync) before I could see it again on the ipod. > > I believe I have saved copies of my iTunesDB from before and after, so > when I get a chance, I'll see if I can tell what happened. If it's just > that flag, maybe we can add some code to gtkpod make sure it's set right > if a track has associated artwork. >From looking at my old databases, it looks like iTunes set has_artwork=2, artwork_count=0, and artwork_size=0, when they should have been 1, 1, and non-zero, respectively. The one complaint I had with gtkpod is that simply updating files from disk didn't make the artwork reappear, presumably because gtkpod didn't notice a change. It might be beneficial to check the iTunesDB artwork fields on an update from disk and make sure that they are set if gtkpod believes the track has artwork. Michael -- Michael Tiffany ti...@ti... http://www.tiffman.com |
From: Jorg S. <Jor...@gm...> - 2007-06-25 15:44:14
Attachments:
gtkpod-gapless-mp3-3.diff
|
Michael Tiffany wrote: > On Mon, 2007-06-25 at 00:07 -0400, Todd Zullinger wrote: >> Thank you Michael! I have more than a few albums that will benefit >> from your effort. :) > > That's what got me interested in the first place: too many live albums, > bootlegs, and progressive-y albums with multi-track songs and > whatnot. :) > >> I did find some tracks that don't update properly. Poking a bit it >> seems that get_header() fails for these tracks. They were encoded >> with Lame 3.96r (which should translate to 3.96.1). eyeD3 reads the >> lame tags just fine, as does madplay (-v -T). madplay does report an >> error when playing the file (even though it plays fine). The error >> is: "error: frame 0: lost synchronization." I haven't looked in the >> madplay source yet to see what might be causing that message. > > manpage says "If encountered at the beginning of a file, this means the > file contains something other than an ID3v2 tag before the MPEG audio > data." > >> I've put one of the offending files online in case someone wants to >> debug a little: >> >> http://www.dmsi.cc/~tmz/10-take_the_veil_cerpin_taxt.mp3 >> >> It would just happen to be one of the larger files from the album at >> 17MB. :) > > For this file at least, the ID3 header is 10 bytes longer than it should > be, so the frame header's not where I (or madplay) think it should be. > Not sure why (my guess is that the ID3 extended header was meant to have > been written and the flag set, but not sure), but attached is a patch > encompassing your and my changes which should fix it. If you (or > anyone) have any files that aren't fixed by this patch, post them and > I'll give them a look. > > Michael Thanks Michael, thanks Todd for your great work. I've gone through the patch and did some minor changes to the "update from track" functionality, ironing out some pre-existing (i.e. old) bugs along the way. I would be grateful if someone could test this patch before submitting to SVN -- I'm not exactly into "gapless" :-/ Cheers, JCS. |
From: Todd Z. <tm...@po...> - 2007-06-25 17:56:20
|
Jorg Schuler wrote: > I've gone through the patch and did some minor changes to the > "update from track" functionality, ironing out some pre-existing > (i.e. old) bugs along the way. Ah, cool. I know there were some corner cases where a track could get updated and not cause the db to be flagged as changed. I'll try to watch if I notice them anymore. > I would be grateful if someone could test this patch before > submitting to SVN -- I'm not exactly into "gapless" :-/ This seems like a good candidate for a branch, since it might take a few iterations to get any little kinks worked out and properly integrated into the UI. And it'd be good to not slow down work toward a release that's compatible with the latest libgpod (I'm actually surprised there haven't been mails already about the released gtkpod not building with the released libgpod :). Any objections to a gapless_playback branch? --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The trouble with most people is that they think with their hopes or fears or wishes rather than with their minds. -- Will Durant |
From: Todd Z. <tm...@po...> - 2007-06-25 18:14:47
Attachments:
gtkpod-gapless-mp3-4.diff
|
Michael Tiffany wrote: > That's what got me interested in the first place: too many live > albums, bootlegs, and progressive-y albums with multi-track songs > and whatnot. :) I have less live albums than albums that simply run together. Same difference though. > manpage says "If encountered at the beginning of a file, this means > the file contains something other than an ID3v2 tag before the MPEG > audio data." Ha, I had found that by grepping the source. Who would think to look in the man page for such informative information? ;) I'm not sure why I have files like this, though I seem to have more than a few of them. I tried recreating this condition, thinking it was the version of lame I used at the time (3.96.1 for the few I noticed last night), or maybe the tagger (eyeD3), but I didn't manage to reproduce it. It might have been an older version of eyeD3 that I didn't check. Anyway, thanks for whipping up a fix so quickly. I had to move the get_first_header() call up a bit, as it was gtkpod would just hang and use up 100% cpu when I tried to update. I don't quite know what the problem was, I guessed it had to do with seeking in the file prior to that (but that was just a guess). Attached is version 4 of the patch, against revision 1589. While I was editing I noticed some places where the indentation was odd, probably due to differences in our editor settings for tab widths ans such. I hope you don't mind that I ran indent on it? As I said in a reply to Jorg's message, I think a branch would be good to work on this further. If no one objects, I'll create one soon and check this stuff in. Do you have any particular ideas for integrating it into the UI? One idea I have is to add a checkbox in the details window to control the track->gapless_track_flag setting (and don't automatically set it in mp3_read_gapless()). With any newly added or updated tracks the gapless data will be read (if possible) and should be available. If it's not, we can then disable the checkbox in the details window. It might even be good to state in the tooltip or somewhere that the checkbox is only available when gapless data can be read from the file so that people know why it's disabled for some files. We could also let them know they need to update current tracks or even try to update them from the file if the gapless checkbox is toggled (and prompting with a dialog if reading the gapless data failed?). It might take less characters to code this than it has for me to describe it. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Don't take life seriously, you'll never get out alive. |
From: Todd Z. <tm...@po...> - 2007-06-27 19:58:23
|
Hola Nick, Nicholas Piper wrote: > Try the attached patch and see what you think. Yeah, that's it. I didn't test it on anything other than a track instance yet, but it seemed to work nicely. Thank you! --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When crypto is outlawed, AtZoMJJzWM2GwNIxsO6ey1gYcHl4IqItK/kb5ABKzt0=3D |
From: Nicholas P. <nic...@ni...> - 2007-06-28 10:49:22
|
Todd, On Wed, 27 Jun 2007, Todd Zullinger wrote: > Nicholas Piper wrote: > > Try the attached patch and see what you think. > Yeah, that's it. I didn't test it on anything other than a track > instance yet, but it seemed to work nicely. Thank you! I've committed it to libgpod trunk, r1608. Nick |
From: Tino K. <tin...@gm...> - 2007-06-25 18:42:58
|
On Mon, Jun 25, 2007 at 14:14:40 -0400, Todd Zullinger wrote: [...] > Do you have any particular ideas for integrating it into the UI? One > idea I have is to add a checkbox in the details window to control the > track->gapless_track_flag setting (and don't automatically set it in > mp3_read_gapless()). Why a checkbox control at all? What should it do? My impression is that a user would like to get gapless playback whenever it is available. > With any newly added or updated tracks the gapless data will be read > (if possible) and should be available. If it's not, we can then > disable the checkbox in the details window. I would just suggest a flag that shows if a track has gapless information. Regards, Tino |
From: Todd Z. <tm...@po...> - 2007-06-25 18:52:58
|
Tino Keitel wrote: > Why a checkbox control at all? What should it do? My impression is > that a user would like to get gapless playback whenever it is > available. Good questions. :) Well, there is a flag in the iTunesDB, gapless_track_flag. Maybe the default should be to enable it anytime gapless data can be produced =66rom a file, but it still seems like a nice thing to let users override this if they want. Or not? The gapless data is available in most mp3's created with lame, and just because the encoder stores the padding data doesn't mean the album should be played back gaplessly, does it? I'm not sure that it would hurt anything if it did though. --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reason obeys itself; and ignorance does whatever is dictated to it. -- Thomas Paine |
From: Tino K. <tin...@gm...> - 2007-06-25 19:08:36
|
On Mon, Jun 25, 2007 at 14:52:54 -0400, Todd Zullinger wrote: > Tino Keitel wrote: > > Why a checkbox control at all? What should it do? My impression is > > that a user would like to get gapless playback whenever it is > > available. > > Good questions. :) > > Well, there is a flag in the iTunesDB, gapless_track_flag. Maybe the > default should be to enable it anytime gapless data can be produced > from a file, but it still seems like a nice thing to let users > override this if they want. Or not? > > The gapless data is available in most mp3's created with lame, and > just because the encoder stores the padding data doesn't mean the > album should be played back gaplessly, does it? I'm not sure that it > would hurt anything if it did though. I just looked around a bit in iTunes and I didn't found an option to disable it, so even iTunes seems to enable it for all tracks. Regards, Tino |
From: Michael T. <ti...@ti...> - 2007-06-25 19:31:38
|
> On Mon, Jun 25, 2007 at 14:52:54 -0400, Todd Zullinger wrote: >> Tino Keitel wrote: >> >> The gapless data is available in most mp3's created with lame, and >> just because the encoder stores the padding data doesn't mean the >> album should be played back gaplessly, does it? I'm not sure that it >> would hurt anything if it did though. > > I just looked around a bit in iTunes and I didn't found an option to > disable it, so even iTunes seems to enable it for all tracks. iTunes does enable it for all tracks. I think turning it on by default is just fine, as you won't notice a difference on non-gapless albums where the amount of silence changes by a bit. Michael -- Michael Tiffany ti...@ti... http://www.tiffman.com |
From: Todd Z. <tm...@po...> - 2007-06-25 19:30:54
|
Tino Keitel wrote: > I just looked around a bit in iTunes and I didn't found an option to > disable it, so even iTunes seems to enable it for all tracks. I don't no what this checkbox does, but look in the info for a track in iTunes, on the Options tab. There's a box for "Part of a gapless album". I suppose it's more likely to control the gapless_album_flag than the gapless_track_flag. If so, then the gapless_album_flag is the one that ought to be in the details window (and the gapless_track_flag can always be set then). Does that seem more reasonable? Can you enable that in iTunes for a track and see which of the two gapless_*_flags it sets? --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Over himself, over his own mind and body, the individual is sovereign. -- J.S. Mill, On Liberty, 1859, "Introductory" |
From: Michael T. <ti...@ti...> - 2007-06-25 19:34:23
|
> Tino Keitel wrote: >> I just looked around a bit in iTunes and I didn't found an option to >> disable it, so even iTunes seems to enable it for all tracks. > > I don't no what this checkbox does, but look in the info for a track > in iTunes, on the Options tab. There's a box for "Part of a gapless > album". I suppose it's more likely to control the gapless_album_flag > than the gapless_track_flag. If so, then the gapless_album_flag is > the one that ought to be in the details window (and the > gapless_track_flag can always be set then). Does that seem more > reasonable? > > Can you enable that in iTunes for a track and see which of the two > gapless_*_flags it sets? That checkbox sets the gapless_album_flag. The gapless_album_flag does *nothing* on the ipod. It's use is in iTunes, to disable crossfading for gapless albums (because it would sound silly). My guess is we don't care about it too much, until a gapless linux media player looks for that flag. Michael -- Michael Tiffany ti...@ti... http://www.tiffman.com |
From: Todd Z. <tm...@po...> - 2007-06-25 20:02:14
|
Michael Tiffany wrote: > That checkbox sets the gapless_album_flag. The gapless_album_flag > does *nothing* on the ipod. It's use is in iTunes, to disable > crossfading for gapless albums (because it would sound silly). My > guess is we don't care about it too much, until a gapless linux > media player looks for that flag. Thanks for clarifying that. I agree that it doesn't seem worth worrying about then (at least not now). --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I never vote for anyone; I always vote against. -- W.C. Fields |
From: Tino K. <tin...@gm...> - 2007-06-25 19:39:37
|
On Mon, Jun 25, 2007 at 15:30:47 -0400, Todd Zullinger wrote: > Tino Keitel wrote: > > I just looked around a bit in iTunes and I didn't found an option to > > disable it, so even iTunes seems to enable it for all tracks. > > I don't no what this checkbox does, but look in the info for a track > in iTunes, on the Options tab. There's a box for "Part of a gapless > album". I suppose it's more likely to control the gapless_album_flag > than the gapless_track_flag. If so, then the gapless_album_flag is > the one that ought to be in the details window (and the > gapless_track_flag can always be set then). Does that seem more > reasonable? It seems to be disabled per default. However, playback in iTunes as well as when the tracks are copied to the iPod is gapless even with this checkbox turned off. > Can you enable that in iTunes for a track and see which of the two > gapless_*_flags it sets? How can I check this? Regards, Tino |