wrong mp3 track duration and wrong crossfader time

Bug #1405832 reported by Alex
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
High
Unassigned

Bug Description

The duration time of some mp3 files is wrong. If such a file is played then the NEXT crossfader time is very short (about 1-2s instead of 10s) if started by "Überblenden" button while in Auto-DJ list.

example of attached file:

shown by mixxx: 18:54
shown by nautilus: 3:08
shown by mp3diags: 3:08

Tags: soundsource
Revision history for this message
Alex (schneider-abg) wrote :
Revision history for this message
Alex (schneider-abg) wrote :

bug is reproducible with mixxx 1.11.0 at ubuntu 12.04 (64 Bit)

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

The file seems to have same tagging issues:
TagLib: MPEG::XingHeader::parse() -- Xing header doesn't contain the total stream size.

The wrong duration is read from the ID3 tags of the file. Currently the information in the corresponding TrackInfoObject is not updated in SoundSourceProxy::open() as indicated by the comments in the code. I'm not sure if those comments are still valid and why the duration and other audio properties of the TrackInfoObject are not updated.

All these issues are already fixed in the new SoundSource API branch. In SoundSourceProxy::open() all metadata in TrackInfoObject about the audio stream that has been read from the tags of the file is now replaced with the actual values reported by the opened AudioSource.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

But now another problem occurs: After the track has been opened and its audio properties have been adjusted it appears twice in the library.

1. Copy file and "Rescan Library":
- Original track: Duration = 18:54, Bitrate = 32
2. Play the track:
- Original track: Duration = 18:54, Bitrate = 32
- Updated track: Duration = 3:08, Bitrate = 191
WRONG: Track has been duplicated!
3. Play the original track:
- Original track: Duration = 18:54, Bitrate = 32
- Updated track: Duration = 3:08, Bitrate = 191
3. Analyze the original track:
- Original track: Duration = 3:08, Bitrate = 191
- Updated track: Duration = 3:08, Bitrate = 191

This only happens if the file is played immediately in step 2 after adding it to the library. If it is analyzed first in step 2 then we end up with only a single track as expected:

1. Copy file and "Rescan Library":
- Duration = 18:54, Bitrate = 32
2. Analyze the track:
- Duration = 3:08, Bitrate = 191
OK

For each file only a single track should appear in the library, i.e. the file path must be unique for each track. Do we need to open another bug for this issue?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

> Do we need to open another bug for this issue?

Yes.
It this one solved then?

Changed in mixxx:
status: New → In Progress
assignee: nobody → Uwe Klotz (uklotzde)
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Wrong duration bug fixed by:
https://bugs.launchpad.net/mixxx/+bug/1156569
https://github.com/mixxxdj/mixxx/pull/411

After the file has been opened (i.e. by analyzing or loading) the duration is displayed correctly.

Testing with a fresh library did not produce a second entry for the same file.

Changed in mixxx:
status: In Progress → Fix Committed
Changed in mixxx:
milestone: none → 2.1
tags: added: soundsource
Changed in mixxx:
importance: Undecided → High
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7768

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.