Code review/Re-fix multisession disc handling (commit 14788fddab63)

[GoogleCodeExporter]

Commit 14788fddab63 removed special handling for calculating track offsets used 
on multisession discs when possible, as cdparanoia does not correctly handle 
multisession discs. As a result, cdparanoia does not correctly calculate the 
length of the final audio track of a multisession disc which has a final data 
track, and overestimates its length by 150 (session lead-out length) + 2 
(session lead-in length) = 152 seconds (i.e. 11400 sectors), as described in 
http://wiki.musicbrainz.org/Disc_ID_Calculation#Multi-session_.28audio_.2B_data.
29_CD.

This commit thus (re-)introduces issues on drives which hang when the lead-out 
is read with cdparanoia.  The effects of this change should be reverted by 
using a cleaner method than that previously employed to calculate the correct 
length of a final track of a multisession disc where possible (i.e. when a TOC 
reader other than cdparanoia is used).

Original issue reported on code.google.com by comradec...@gmail.com on 22 Aug 2012 at 9:57

[GoogleCodeExporter]

Further analysis suggests that the problem is (most probably) limited to 
FreeBSD.  Specifically, the issue appears to be due to some upstream 
(Debian-derived) patches to add FreeBSD support to cdparanoia.  These patches 
do not add FreeBSD code to account for multisession discs in 
interface/common_interface.c (the vanilla Linux code does so using the 
CDROMMULTISESSION ioctl).

Will look into submitting patches to upstream packages to resolve this 
(Debian-kFreeBSD and FreeBSD ports tree).

Closing as WontFix since it's not a rubyripper problem.

Original comment by comradec...@gmail.com on 26 Aug 2012 at 2:23

• Changed state: WontFix