View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002930 | MMW v4 | Burning / Disc Handling | public | 2007-03-19 18:48 | 2007-10-26 02:06 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.0 | ||||
| Summary | 0002930: Audio CD burns have occasional gaps | ||||
| Description | I tested audio CD burns in 1023 and noticed that occasionally there are gaps in the audio where such gaps do not exist in the original source material. This has been reported on occasion with MM 2.5.5. Please let me know what I can do you help solve this. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1092 | ||||
|
|
Yes, this problem is described at http://www.mediamonkey.com/forum/viewtopic.php?t=14953 for MM 2.5.5 According to what the users have written so far the problem is casued by decoding of some mp3 files. Could you please upload such a mp3 to ftp so that I can reproduce this problem? |
|
|
I tested this further and it seems that the gaps are not associated with a particular track, but rather with a particular track AND the position to which it is burnt on the CD. e.g. -CD1 contains track 1-18. Gaps occur in Tracks 11 and 14 (verified with both MM and WMP) -CD2 contains track x, 11, y. On this CD (burnt with identical settings) track 11 does NOT exhibit the problem observed with CD 1. -CD3 contains track 1-18 (exactly like CD1). Gaps occur in exactly the same manner as with CD1 I'll zip up the 17 tracks that I've used to replicate this problem. Try burning a CD with them and see if you can replicate. |
|
|
I've unzipped the 18 tracks and I've tried to replicate this problem: -CD1 contains track 1-18. A small 1 sec gap occurs only in the Track14 (time 3:35) -CD2 contains only the track 14 (Paul Simon - Graceland). No gaps. -CD3 contains track 1-18 (exactly like CD1). No gaps seem to be presented. -CD4 contains track 1-18 (exactly like CD1). No gaps seem to be presented. So it looks like a really occasional problem and I am not sure whether we can do something about it. |
|
|
Tested build 1058 with a single CD and the same set of tracks. The problem still occurs exactly as it did (tracks 11 and 14) in earlier builds. We need to determine whether it's a problem in MM or in hpcde and either fix the issue or get hpcde to fix it. Note: I performed the following additional tests -Converted tracks 11 and 14 to WAV --> no problems existed in the wav files -Disabled on-the-fly conversion in the burn dialog --> the problem did not occur So it seems that the issue may be somehow related to on-the-fly conversion... |
|
|
Note: I set a relationship between 0003367 and 0002930 since both seem to occur only with On the fly burning enabled, which makes me think that they may be related. |
|
|
No, it is not true that this occurs only with On the fly burning enabled. 1. according to my testing. 2. According that the complaints came from MM version 2.5 where On the fly audio burning was not implemented! |
|
|
Assigning to Jiri to rewrite some parts of buffering, because it looks like it could cause problems in on-the-fly burning (waiting times, etc.). |
|
|
Fixed in build 1059 - I can't say whether this fixes the issue, but the fact is that buffering wasn't written well and could have caused performance problems. It's rewritten now, so hopefully it helps. |
|
|
The Jiri's changes probably don't fix the problem, because this problem is related also to audio burning without using on-the-fly buffer. But the Jiri's changes could (hopefully) solve the bug 0003367. According to Primo I changed the burning code so that writing is performed per 32 blocks instead of 40 blocks that could solve this problem. Needs to be tested! Fixed in build 1059. |
|
|
Verified 1063. |
|
|
As described at: http://www.mediamonkey.com/forum/viewtopic.php?t=21256 there are still some problems. |
|
|
Remarked as resolved for the next release, becasue 3700 probably fix this. Fixed in build 1083. |
|
|
Tested 1087 and the bug is still reproducible. I'll save the set of tracks that reproduces this. The gap is introduced at: - 1:06 of the sixth song (I heard it through the grapevine) - 1:04 of the eighth song (Is this love) - 2:52 of the tenth song (I've got to see you again) |
|
|
I cannot reproduce it (with your set of tracks), but I have added some debug messages to be able to pinpoint the root of this problem. The messages are included in build 1090. Could you try it again with 1090 and send me a debug log of your burning process? Questions: Is it reproducable everytime or does it depend on a particular burn speed / burn mode? Note: I have also added hpCDe sample app (/MMBugs/bug2930/Sample app/AudioBurner.exe) so that we could find out whether it is only our problem (or their). |
|
|
Log from build 1091 is posted to the ftp server. As far as reproducibility: it occurs consistently at 1:06 of the 6th track and 2:60 of the 10th track (tested on 3 burns). When I tested with the AudioBurner test app, the test turned out to not be a a perfect test since one of the tracks on my set of test files is an OGG track and the test app won't convert OGG. That said, I was unable to find any gaps in the entire CD which implies that it probably does work correctly--tested at 48x/CD-text enabled/disc at once, same settings that trigger teh bug in MM. (to perform a better test, I would need to find a series of MP3-only tracks that will consistently trigger the problem in MM and then attempt to reproduce with the test app). As far as changes in parameters effecting whether this bug occurs, I'll test further tomorrow... |
|
|
Thanks to your debug log I was able to pinpoint the problem and I've most probably fixed this in build 1092. I've uploaded the fixed hpCDBurn.dll to the FTP server so that you could test it today. |
|
|
fyi: tested the dll and it solved the bug. |
|
|
Verified 1093. |
