FLAC files don't convert

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Try to convert a folder of 10 albums in FLAC format to Apple Lossless

How about the reproducibility (always, sometimes, rarely, ...)?
Always fails, for certain tracks. Those tracks always fail. About 5% of all 
tracks fail, and I don't know the cause. I'm happy to provide you a sample.

The conversion gets to 99+ % and just hangs there

What is the expected output? What do you see instead?
Expect 100% conversion

What version of the product are you using? On what operating system?
144.0, on MacOSX 10.8.4

Please provide any additional information below.
Once 4 files are stuck, the conversion stops. This makes the software useless 
for me. Sometimes though, after several minutes sitting at 99%, with 0:00 
remaining, it'll finish and move on.

Original issue reported on code.google.com by m...@msnmedia.com on 28 Jul 2013 at 8:57

Attachments:

• [Screen Shot 2013-07-28 at 1.54.34 PM.png](https://storage.googleapis.com/google-code-attachments/xld/issue-190/comment-0/Screen Shot 2013-07-28 at 1.54.34 PM.png)

[GoogleCodeExporter]

Can you send me the problematic file?

Original comment by tmkkmac on 29 Jul 2013 at 4:26

[GoogleCodeExporter]

I decided to wait a long time, and they appear to all be finishing. So they 
only bug (feature?) that I would report is that the percentage complete is way 
off, and that some tracks rip almost instantly (and finish instantly) while 
others pause quite a while near the 99% mark.

Original comment by m...@msnmedia.com on 29 Jul 2013 at 5:57

[GoogleCodeExporter]

ALAC encoding tends to stutter at ~100% because it rewrites a whole file to 
append tags. This is noticeable when the output file is large, or the output 
disk is slow (i.e. network drive, USB thumb drive). But it should never freeze 
forever.

Original comment by tmkkmac on 29 Jul 2013 at 5:59

[GoogleCodeExporter]

I also experience this behavior, going from FLAC to ALAC.  Not only does XLD 
hang at 99% for a while on each file, but it seems to take a lot more of the 
total system resources that I feel it should.  Everything stalls while it's 
finishing.

Original comment by andrew.y...@gmail.com on 10 Sep 2013 at 8:42

[GoogleCodeExporter]

I have converted thousands of files though, and it always works, so I
consider this just a display glitch, not a true issue.

Once in a while the app quits though, but when I open it and continue
converting, it always works, so it's not a corrupt file. Perhaps just a
memory leak. I convert songs for hours and days at a time.

Original comment by m...@msnmedia.com on 11 Sep 2013 at 1:56

[GoogleCodeExporter]

I'm having the same problem; FLAC to ALAC eventually finishes, but may pause at 
99% for 1-20 minutes, sometimes longer.

Original comment by Dr.W.Bo...@gmail.com on 23 Oct 2013 at 11:30

[GoogleCodeExporter]

Several versions ago, this was not an issue. This happened along the way, via 
an "update".

Original comment by chambina...@gmail.com on 4 Apr 2014 at 2:29

[GoogleCodeExporter]

the issue seems to be caused by the images attached to the Flac files. I 
removed the tag and XLD was able to convert with no problem

Original comment by gboug...@gmail.com on 8 May 2014 at 4:01

[GoogleCodeExporter]

Experiencing the EXACT same problem. 
Files are stuck at 99,9% for longer periods of time. Often stuck longer at the 
last 99,9% than the duration of the ripping of entire track.

Converting from flac to alac: same as input.
Enabled:
+ add tags to output file when possible
+ embed cover art into files
+ scale large images when embedding cover art
+ set the compilation flag automatically
+ load the following files as cover art automatically
+ preserve unknown metadata if possible

Using Mac 2011 with external USB 2.0 drive, OS X 10.9.4 and 147.0 (latest at 
this time). 

Original comment by kmuhic@gmail.com on 16 Jul 2014 at 3:57

[GoogleCodeExporter]

In addition to previous post:

Disabling "embed cover art into images" does NOT eliminate the issue. Problem 
persists.

Interesting note. "cancelling all tasks" while files stuck at the final 
99%-199% takes a long period to stop.
XLD does not stop the ripping immediately and waits for a long period of time 
to cancel the task. Perhaps the same amount as if it would finish it.

Queued tasks are cancelled immediately.

Original comment by kmuhic@gmail.com on 16 Jul 2014 at 4:09

[GoogleCodeExporter]

Having same issue, looking for a cure. This never seemed to happen before, but 
has been happening a lot lately.

Original comment by griffd2...@gmail.com on 28 Jul 2014 at 2:46

[GoogleCodeExporter]

OK I just remembered that I had recently changed my threads from 4 to 8. Well, 
I just changed it back to 4, processed the same FLAC files with the same 
settings (otherwise), and there was NO hanging! My guess is there is some file 
system contention somewhere when there are too many threads active at once - 
perhaps a deadlock situation. I am using a 4-core MacBook Pro with a Crucial 
M500 SSD (and plenty of free disk space). Can anyone else correlate their 
issues to this type of config?

Original comment by griffd2...@gmail.com on 28 Jul 2014 at 3:01

[GoogleCodeExporter]

On my 4-core iMac, I noticed (and was annoyed by) this hanging behaviour when I 
had the Max # of Threads set to 4.  When I set it to two, the problem 
disappears.  I agree with who-ever said that this problem was introduced over 
the last few updates somewhere.

Original comment by linc.pi...@gmail.com on 5 Oct 2014 at 6:13

[GoogleCodeExporter]

Issue 285 has been merged into this issue.

Original comment by tmkkmac on 18 Oct 2014 at 4:03

[GoogleCodeExporter]

Issue 277 has been merged into this issue.

Original comment by tmkkmac on 18 Oct 2014 at 4:04

[GoogleCodeExporter]

Open XLD.app/Contents/PlugIns/XLDAlacOutput.bundle/Contents/Info.plist and 
change XLDAlacOutputUseDiskCache key to true. Then see how the status changes.

Original comment by tmkkmac on 18 Oct 2014 at 4:05

[GoogleCodeExporter]

Alright, once XLDAlacOutputUseDiskCache is set to true, FLAC and WAV files seem 
to convert in a much more reasonable amount of time. So I think that may have 
fixed the problem, whatever it was. I'll report back on this thread if it 
recurs.

Original comment by jwgreenb...@gmail.com on 18 Oct 2014 at 5:09