IPB

Welcome Guest ( Log In | Register )

Songbird Issue / Question - ID3v2?
Sunraycer
post Jul 18 2011, 06:01
Post #1





Group: Members
Posts: 10
Joined: 18-July 11
Member No.: 92356



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...
Go to the top of the page
+Quote Post
 
Start new topic
Replies
bryant
post Jul 19 2011, 18:03
Post #2


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



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.
Go to the top of the page
+Quote Post
Sunraycer
post Jul 20 2011, 07:11
Post #3





Group: Members
Posts: 10
Joined: 18-July 11
Member No.: 92356



QUOTE (bryant @ Jul 19 2011, 11:03) *
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?

QUOTE (bryant @ Jul 19 2011, 11:03) *
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?

Go to the top of the page
+Quote Post
bryant
post Jul 20 2011, 17:40
Post #4


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (Sunraycer @ Jul 19 2011, 23:11) *
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.
Go to the top of the page
+Quote Post
Sunraycer
post Jul 20 2011, 18:27
Post #5





Group: Members
Posts: 10
Joined: 18-July 11
Member No.: 92356




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

QUOTE (bryant @ Jul 20 2011, 10:40) *
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).


smile.gif 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?

Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th April 2014 - 15:48