doesn't work correctly with new upcoming flac 1.3

[GoogleCodeExporter]

1) Please describe the steps to reproduce the situation:
a.build & install latest flac, currently 1.3.0pre4
b.use RR to rip & encode a track to flac
c.

2) What is the expected output? What do you see instead?
Expected to produce a flac file
What happens is only a small flac file is produced, around 78kB here. Has 
headers & tags but no content

3) What version of rubyripper are you using? On what operating system? The
gtk2 of commandline interface?
Using current git as of 05/12 ( Rubyripper 0.7.0a1

4) Is this not already fixed with the latest & greatest code? See for
instructions the Source tab above.

5) Does the problem happen with all discs? If not, please attach
the output of cdparanoia -Q with a disc that gives trouble.
All

6) Please explain why this change is important for you. Also, how many
users would benefit from this change?
Will be releasing soon & eventually on various distros

Please provide any additional information below. The more useful
information provided, the sooner the issue will be fixed.

Sample encode attached

Note on flac build - tried with both static & shared build of flac 1.3.0pre4, 
same results
New flac works fine with abcde, ect.

Note that ruby versions older than 1.9 are no longer supported. You are
advised to upgrade instead.

Original issue reported on code.google.com by mc631man on 12 May 2013 at 5:50

Attachments:

• [01 - Who Do You Love.flac](https://storage.googleapis.com/google-code-attachments/rubyripper/issue-568/comment-0/01 - Who Do You Love.flac)

[GoogleCodeExporter]

I can confirm this. manual flac encode of the resulting wav files works fine, 
but rubyripper itself creates tiny 1 second encodings.

Original comment by rasmus.s...@gmail.com on 12 Jun 2013 at 4:32

[GoogleCodeExporter]

Unfortunately this is becoming  a significant defect  as flac-1.3 starts to 
become the default version.
(at best here can get 5 sec.'s

Original comment by mc631man on 27 Jul 2013 at 6:46

[GoogleCodeExporter]

I confirm that the issue exists but don't have a good solution at the moment.  
It seems to be tied to a change in the console output of flac-1.3 interacting 
badly with IO.each.  Namely, where 1.2.1 and below used a carriage return to 
update the encoding progress in the console, 1.3 uses backspace characters, 
which apparently fails quietly when IO.each is used, perhaps because due to 
behavior with a filled pipe.

At the moment, a workaround would be to change the flac executable to be 
invoked with the "-s" flag (which stops printing the output of the encoding 
progress) by patching the definition of "binary" in 
lib/rubyripper/codecs/flac.rb to return "flac -s" instead of "flac".  This 
isn't a good long-term solution, however, which would require reworking the 
definition of "launch" in lib/rubyripper/system/execute.rb to do something 
other than "stdin.each" in the block passed to PTY.spawn.

Original comment by comradec...@gmail.com on 11 Aug 2013 at 7:50

• Changed state: Accepted

[ACOdell]

More of a heads up than anything.

I just used this on Debian Jessie and I encountered the same problem (using the stable branch). Luckily, the quick fix from 3 years ago still worked after I edited the source file.

[bleskodev]

Hello, I'm using flac 1.3.1 with master branch without problems. I do not currently recommend using stable branch with this fork because the stable branch is very old (around 4 years). The code was abandoned several years ago and I have made a number of fixes on the main branch.

If you have time and energy, please test the latest version on the main branch and confirm that the bug is fixed (this would give me an excuse to close this issue as fixed; I would have an external confirmation that this works...)

[olehj]

I just cloned the git and use flac 1.3.1. I ripped a song to flac successfully.

[doc75]

Working fine with flac 1.3.1 and ruby 1.9.

[bleskodev]

Closed because it seems the problem has been fixed in the latest version.