Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files not processing correctly #5

Closed
Sappharad opened this issue Aug 27, 2012 · 5 comments
Closed

Files not processing correctly #5

Sappharad opened this issue Aug 27, 2012 · 5 comments
Assignees
Labels

Comments

@Sappharad
Copy link
Owner

I've received a few reports of files not processing correctly.

  • One user reported that the last 20% of some their MP3's was distorted in 1.0.1, but they haven't been able to reproduce the problem in 1.0.2
  • Another user reported that their audio became distorted and the volume drastically fluctuated. This user said that the Windows version of MP3Gain worked fine for the same files.

I have not been provided with any samples of these problems, nor have I been able to produce them myself. If anyone encounters them and could provide a sample file that works on Windows but not on OS X, that would be great.

@ghost ghost assigned Sappharad Nov 30, 2012
@Sappharad
Copy link
Owner Author

I finally received a sample file from a user that they could used to reproduce the problem mentioned above. It appears that the damaged files contain some of the console output text from MP3Gain, and other data that I can't identify. This data overwrites parts of the files, but not all of it because the music is still audible with glitches.

Unfortunately, the same sample file does not produce the corruption on my machine. The user was running Mac OS X 10.7.2, so I installed a fresh copy of that in VMWare, but I wasn't able to produce the problem there either. From what I can tell, the problem appears to be specific to some machines.

Since the corrupt files contain data that is usually output to stderr, I will create a build without any console logging to see if it helps the problem. I don't know why output to stderr would be written into the output file, but at least it's something I can try disabling to see what happens.

@teh-Michael
Copy link

I got the Problems to, it was my mistake. If you click on the Apply Gain Button you don't see the Track Gain after the Process is done (as in the Windows Version). If you click the Apply Gain Button a second time and Mp3 is going to be gained another time it will break.

@Sappharad
Copy link
Owner Author

The situation you're describing was reported here:
#4

But I couldn't reproduce the problem and closed the issue. The behavior you'd expect (the values update after clicking apply) is what is supposed to happen, and how it works for me. It seems that for some people, the application works 100% correctly, and for others, it doesn't work right at all. I'm not sure what I can do, because I can't fix something that works fine on all of my machines.

@Sappharad
Copy link
Owner Author

I am now able to reproduce the file corruption problem in 1.0.2.
A user was able to identify a way to reproduce it after noticing that MP3's in one folder experienced the problem but not in another. The problem is triggered by certain long folder or filenames. I have not been able to determine the exact characteristics that cause the problem to occur, but when I process a folder full of files where the folder name is several words, contains spaces, and all of the files are long and contain spaces, files after the first one processed become corrupted.

I don't understand why it's specific to certain pathnames, but now that I can reproduce the problem I was able to correct it by enabling the QuietMode flag for MP3Gain. This fix will be included in the next release, which I hope to push out in the next few days.

@Sappharad
Copy link
Owner Author

This problem was fixed in the 1.1 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants