Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Songbird Issue / Question - ID3v2? (Read 13200 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Songbird Issue / Question - ID3v2?

When loading a a WavPack file into Songbird it shows the incorrect track time.  It shows the other tags, artist, etc, correctly.  After playing the track for a few seconds, the track time updates to the correct time.  And stays correct from then on. 

Does anyone have an idea of why this is?  I was thinking that maybe it's due to the Ape or ID3v1 tags.  Reading some other posts on this board I'm wondering if it has to do with WavPack files having the metadata at the end of the file?


Does anyone know why WavPack supports only ID3v1 and not ID3v2?  Just curious...

 

Songbird Issue / Question - ID3v2?

Reply #1
I was thinking that maybe it's due to the Ape or ID3v1 tags.


File tags don't store the duration of a file, and those tags are at the end of the file, not the start.

Songbird Issue / Question - ID3v2?

Reply #2
I was thinking that maybe it's due to the Ape or ID3v1 tags.


File tags don't store the duration of a file, and those tags are at the end of the file, not the start.



Seems like Start Time and End Time are part of the extended tag for ID3v1 (from wikipedia), no?

How would a player determine track length then?

Songbird Issue / Question - ID3v2?

Reply #3
Seems like Start Time and End Time are part of the extended tag for ID3v1 (from wikipedia), no?
Start time and end time as arbitrary points to exclude portions of audio that the user doesn’t want played, yes. Duration, no.

Quote
How would a player determine track length then?
This kind of basic and quite essential technical information should be an indispensible component of the header of any audio format. Granted, there were issues for a while after the large-scale debut of VBR MP3, but there’s no excuse for that sort of thing now (and I know the developer of WavPack is above it!).

Back to your first post:
Does anyone know why WavPack supports only ID3v1 and not ID3v2?  Just curious...
I’m not sure why ID3v1 is supported at all, but my uninformed guess would be that ID3v2 was skipped in favour of the more flexible (e.g. field-neutral) APEv2.

Songbird Issue / Question - ID3v2?

Reply #4
Thanks for your reply.  As you can see I don't really know much about how these things work, but I'd like to learn...someday when I have time.  I guess the player must not be reading the header correctly then.

Anyway, thanks.

Songbird Issue / Question - ID3v2?

Reply #5
It’s actually a little odd that Songbird is not showing the length correctly, and even weirder that it corrects the value after playing starts. I think I have an idea though.

As was said, the total duration of an audio file is a fundamental piece of info and is stored unambiguously in the WavPack header, so it should be available on opening the WavPack file (presumably with the WavPack library). However, it might be that Songbird does not really open the file until it’s actually going to play it, and has some other metadata parser that tries to get basic info (including length) that operates when just browsing (this is, for example, how Rockbox works). Now, if there is a bug in that metadata parser it might get the length wrong at that time, but then once play starts it uses the length that the library returns.

This problem could also be triggered if your WavPack files were created by one of the few programs that [incorrectly] neglect making the finalizing call to the WavPack library that puts the final length in the header (cuesplitter is one). In that case it’s impossible to know the length without seeking out to the end and examining the last audio block, or guessing the length by using the encoding mode and the file length (again, something that I implemented in Rockbox to handle this). A way to test for this would be to grab a file from the WavPack test suite (which are known to be correct) and see how that plays.

The story with WavPack and tags is that WavPack is old enough (it predates FLAC and Monkey’s Audio) that ID3v1 tags were initially the best choice. When Monkey’s Audio APE tags became available I decided to support them also and so there was never a need to deal with ID3v2.

Songbird Issue / Question - ID3v2?

Reply #6
Thanks for the info about tags, David—and hey, I wasn’t aware WavPack was so much older than all those other upstarts.

Songbird Issue / Question - ID3v2?

Reply #7
As was said, the total duration of an audio file is a fundamental piece of info and is stored unambiguously in the WavPack header, so it should be available on opening the WavPack file (presumably with the WavPack library). However, it might be that Songbird does not really open the file until it’s actually going to play it, and has some other metadata parser that tries to get basic info (including length) that operates when just browsing (this is, for example, how Rockbox works). Now, if there is a bug in that metadata parser it might get the length wrong at that time, but then once play starts it uses the length that the library returns.


I think you are right on here.  I downloaded the samples from your site and they acted the same way as my files.  When added to the library the length was displayed incorrectly.  This time before playing it I decided to check the metadata for the file inside Songbird.  It listed the length as part of the metadata and it was incorrect.  When I played the file it showed length, time left, etc always correct in the player, even though the library was wrong.  After playing for several seconds the library corrected itself and then I rechecked the metadata for the file in the library it showed the correct length.

Was there a fix for this in Rockbox that I could pass on to the Songbird developers?  Or do you think it's done this way on purpose for speed or some other reason and they wouldn't want to fix it?

This problem could also be triggered if your WavPack files were created by one of the few programs that [incorrectly] neglect making the finalizing call to the WavPack library that puts the final length in the header (cuesplitter is one).


I used dBpoweramp to make my files.  Seems like a great program from my use.  Any comments about it?


Songbird Issue / Question - ID3v2?

Reply #8
Was there a fix for this in Rockbox that I could pass on to the Songbird developers?  Or do you think it's done this way on purpose for speed or some other reason and they wouldn't want to fix it?

I can't imagine that it was done on purpose...if the files are correct then it's trivial to get the correct duration out of the header. Probably just a simple bug.

But what version of Songbird is this (and what platform)? I didn't think they had native support for WavPack, but I knew there was a plugin written a couple years ago (but it hasn't been updated in a while).

Quote
I used dBpoweramp to make my files.  Seems like a great program from my use.  Any comments about it?

Yeah, dBpoweramp is a great program...no problem there.

Songbird Issue / Question - ID3v2?

Reply #9
Thanks for the info about tags, David—and hey, I wasn’t aware WavPack was so much older than all those other upstarts.

It’s true. WavPack was originally released back in about 1998, but it was just a closed-source, command-line program (no plugins). If I had made a winamp plugin and GUI front-end available and opened the source sooner, there may have never been Monkey’s Audio or FLAC. Of course, one can argue whether having more choices has helped or hurt the situation.

Songbird Issue / Question - ID3v2?

Reply #10

I guess I'll enter the file header thing in to Songbird as a bug.  Thanks.

But what version of Songbird is this (and what platform)? I didn't think they had native support for WavPack, but I knew there was a plugin written a couple years ago (but it hasn't been updated in a while).


  This is with the latest version of Songbird running on Windows.  And it's using the old plugin that was developed a couple years ago.  I asked Daniel to create that plugin because I was having trouble doing it.  The plugin wrapper is pretty basic and the old one can be updated to just extend what versions of Songbird it works with, which is what I had done locally.  I'd thought about releasing it again with just an updated wrapper, but I never really got the time.

I've been ripping some of my CDs again with dBpoweramp and would like to use Wavpack and so I'm back at some of the issues I was having before.

Anyway, updating the wrapper is fairly easy, but the part that Daniel did was build the GStreamer Wavpack library for Windows.  All the source is up on the GStreamer site and I gave it a whirl but was having all sorts of compiler issues with MingW.  Daniel had already built a different decoder so I asked him to do Wavpack also.  The version that he built is fairly old now.  And I was going to see if I could get an updated GStreamer Wavpack windows build (just need gstwavpack.dll file), but didn't have much luck yet.  I'd like to figure out how to do it so I can keep updating it with new versions of GStreamer, or find someone interested in doing it.

There is a site called OSSBuild for Gstreamer that is GStreamer ready for windows compile (I think for VS2008?).  I think that site may be a few GStreamer versions old.  Though I haven't really taken the time to track the Wavpack version to the GStreamer version to the OSSbuild version yet...

Any interest in taking this on or know someone who would?


Songbird Issue / Question - ID3v2?

Reply #11
Okay, that makes a little more sense. I guess one thing I don’t understand is that if Songbird uses GStreamer for all their decoding then it seems like WavPack would come along for free (WavPack is now in the “good” camp), but I guess not.

Anyway, knowing this, it seems likely that your problem might be in the wrapper (the existence of which may answer my question above) or in the old version of GStreamer that you have, rather than in Songbird itself. I am pretty busy these days, but if I get a free moment I’ll see if I can figure out how to build that dll for you (I do have VS2008, anyway).

Thanks for the info! 

Songbird Issue / Question - ID3v2?

Reply #12
Okay, that makes a little more sense. I guess one thing I don’t understand is that if Songbird uses GStreamer for all their decoding then it seems like WavPack would come along for free (WavPack is now in the “good” camp), but I guess not.


They choose not to build all of the CODECs, I don't really know why.  Maybe I remember them mentioning that they couldn't test them all...

Quote
Anyway, knowing this, it seems likely that your problem might be in the wrapper (the existence of which may answer my question above) or in the old version of GStreamer that you have, rather than in Songbird itself. I am pretty busy these days, but if I get a free moment I’ll see if I can figure out how to build that dll for you (I do have VS2008, anyway).


Interesting thing though is that you can add the Wavpack files to the library without the plugin.  It reads all the tags in the file, etc.  You just can't play it without the plugin.  And the track length is wrong when added to the library until it's played.

If you build the dll, I'd be happy to hear the process you end up going through!  Thanks.