MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003483MPDInput Plugins - Filepublic2012-04-08 08:572012-10-05 14:50
Reporterdarkraven 
Assigned Tocirrus 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionunable to reproduce 
PlatformOSOS Version
Product Versiongit 
Target VersionFixed in Version 
Summary0003483: Seeking in APE files is inaccurate
DescriptionI can reproduce issue 0003326 with the latest git version.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0007442)
cirrus (administrator)
2012-09-25 07:51

I don't understand the problem, please be more specific.
(0007470)
cirrus (administrator)
2012-10-04 08:04

Reopen when you post more details about your problem.
(0007471)
darkraven (viewer)
2012-10-04 11:58

when playing file compress with higher compression level (like file compressed with mac -c5000), seeking in these files will be inaccurate (often somewhere after the point you want to seek to).

Currently I recompress my apes with lower level to workaround this problem.
(0007472)
darkraven (viewer)
2012-10-04 12:00

I forgot to add: I notice this when I play ape/cue combinations. Most songs doesn't start at 0:00.

Haven't tested with pure ape.
(0007473)
cirrus (administrator)
2012-10-04 12:02

What does that mean exactly? How do you reproduce, how do you see there's a problem?

Which decoder plugin is used? Which MPD version exactly did you use? (git commit?)
(0007476)
darkraven (viewer)
2012-10-04 16:27

Add a cue file associated with a ape file(and the ape file is encoded with mac -c5000) to playlist, play tracks except the first one. The track should start from 00:00 but instead start from somewhere after the beginning.

Decoder plugin is ffmpeg. I don't know the exact git commit, the package was built at Aug 15, mpd --version says 0.18~git.
(0007477)
cirrus (administrator)
2012-10-04 16:29

MPD does not care about compression levels, it does not even know about it. All it does is forward the seek command to ffmpeg. Maybe ffmpeg is a bit clumsy at seeking.

Can you provide sample files? I don't have any.
(0007480)
darkraven (viewer)
2012-10-05 03:06

Here is the sample file: http://tmp.rorvn.info/7c.ape [^]

And here is an example of seeking in this file:

%time mpc seek 00:15
musics/7c.ape
[playing] #7/7 0:27/0:29 (93%)
volume: 59% repeat: on random: off single: on consume: off
mpc seek 00:15 0.00s user 0.00s system 5% cpu 0.119 total
(0007482)
cirrus (administrator)
2012-10-05 14:50

bugs/0003483/7c.ape
[playing] #1/1 0:15/0:29 (51%)
volume:100% repeat: off random: off single: off consume: off

Looks like it works perfectly. I suggest you check for bugs in the ffmpeg version you use (you didn't tell me which version you use therefore I can't check further). This doesn't look like a MPD issue at all.

- Issue History
Date Modified Username Field Change
2012-04-08 08:57 darkraven New Issue
2012-04-08 08:57 darkraven Status new => assigned
2012-04-08 08:57 darkraven Assigned To => cirrus
2012-09-25 07:51 cirrus Note Added: 0007442
2012-10-04 08:04 cirrus Note Added: 0007470
2012-10-04 08:04 cirrus Status assigned => resolved
2012-10-04 08:04 cirrus Resolution open => unable to reproduce
2012-10-04 11:58 darkraven Note Added: 0007471
2012-10-04 11:58 darkraven Status resolved => feedback
2012-10-04 11:58 darkraven Resolution unable to reproduce => reopened
2012-10-04 12:00 darkraven Note Added: 0007472
2012-10-04 12:00 darkraven Status feedback => assigned
2012-10-04 12:02 cirrus Note Added: 0007473
2012-10-04 16:27 darkraven Note Added: 0007476
2012-10-04 16:29 cirrus Note Added: 0007477
2012-10-05 03:06 darkraven Note Added: 0007480
2012-10-05 14:50 cirrus Note Added: 0007482
2012-10-05 14:50 cirrus Status assigned => resolved
2012-10-05 14:50 cirrus Resolution reopened => unable to reproduce


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker