After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 540993 - Brasero displays (and uses) incorrect track durations
Brasero displays (and uses) incorrect track durations
Status: RESOLVED FIXED
Product: brasero
Classification: Applications
Component: general
0.7.1
Other All
: Normal normal
: 0.7
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-06-30 20:46 UTC by Stephen Irons
Modified: 2008-07-01 10:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stephen Irons 2008-06-30 20:46:56 UTC
Please describe the problem:
While creating an audio CD, Brasero displayed the wrong track duration and burned a bad disk. First, I added some .WAV files to the brasero audio cd project. I then realised that they needed tweaking, so I re-generated the .WAV files from my audio editor. I then removed the files from the brasero project and dragged the new ones (with the same names) into the project.

Brasero kept the duration of the original files. It burned to disk the contents of the second version of the files, but truncated them (if the first version was shorter than the second) or padded them with silence (if the first version was longer than the second).

Steps to reproduce:
1. In Brasero, create a new audio CD project
2. Create two WAV files; I used Audacity export multiple
     * track1.wav, 5MB, 00:30
     * track2.wav, 20MB, 02:00
3. Drag them into Brasero. Brasero reports their duration correctly.
4. Oh dear, they were wrong, I need to change them
5. Overwrite test1.wav and test2.wav with different contents and change the length; once again, I used Audacity
      * track1.wav, 10MB, 01:00
      * track2.wav, 15MB, 01:30
6. Delete the files from Brasero
7. Drag the new test1.wav and test2.wav into Brasero
8. Brasero reports their duration as 00:30 and 02:00, not 01:00 and 01:30 as expected
9. Burn a disk and play it on a CD player. Both tracks are incorrect
      * Track 1 is 00:30 long, and consists of the music in the second version of track1.wav, truncated at 30s
      * Track 2 is 02:00 long, and consists of the music in the second version of track2.wav, padded with silence to 02:00

This behaviour is clearly wrong: it should either use the first versions of track1.wav and track2.wav, or the second version. It should not use the duration of the first version but the contents of the second version.


Actual results:
8. Brasero reports their duration as 00:30 and 02:00, not 01:00 and 01:30 as expected
9. Burn a disk and play it on a CD player. Both tracks are incorrect
      * Track 1 is 00:30 long, and consists of the music in the second version of track1.wav, truncated at 30s
      * Track 2 is 02:00 long, and consists of the music in the second version of track2.wav, padded with silence to 02:00


Expected results:
8. Brasero reports their duration as 00:30 and 02:00, not 01:00 and 01:30 as expected
9. Burn a disk and play it on a CD player. Both tracks are incorrect
      * Track 1 is 00:30 long, and consists of the music in the second version of track1.wav, truncated at 30s
      * Track 2 is 02:00 long, and consists of the music in the second version of track2.wav, padded with silence to 02:00


Does this happen every time?
Yes

Other information:
In order to get the correct duration for track1.wav and track2.wav, you have to close Brasero. I have not tried creating a new project, but that might work too.
Comment 1 Philippe Rouquier 2008-07-01 07:47:08 UTC
Thanks for the report. I can see where the problem comes from. It has to do with the cache brasero keeps internally about all multimedia files. It hasn't been updated after the changes. I guess that if you restart brasero, it'll display correct values (which of course is just a workaround for the bug).
I'll work on it
Comment 2 Philippe Rouquier 2008-07-01 10:14:41 UTC
That's fixed in trunk. We now keep the last modified date and compare to know if we should update information in the cache.