rocky / libcdio-paranoia Goto Github PK

Wondering why no more binary?

$(mkdir_p) is deprecated, and mkdir -p shouldn't be hardcoded, the most modern way I know this should be called is AC_PROG_MKDIR_P in configure.ac and $(MKDIR_P) in Makefile.am files

1. Add AC_PROG_MKDIR_P to configure.ac
2. Change $(mkdir_p) with $(MKDIR_P) in doc/ja/Makefile.am
3. Remove old AC_SUBST and mkdir_p hacks from configure.ac as useless

However if you compare doc/en/Makefile.am with doc/ja/Makefile.am it seems there is more modernisation to be done that would simplify this even futher :)

Hello. I'm trying to configure my CD drive correctly for the use with whipper. When configuring, whipper couldn't defeat the audio cache. @JoeLametta instructed me to check out the output of cd-paranoia -A. The command failed at 'analyzing cache behavior'. I attach cdparanoia.log below.
cdparanoia.log

(not that relevant, but the CD that was in the drive was Slaves and Masters by Deep Purple. after that I managed to get a perfect rip with whipper (with defeat audio cache disabled))
Deep Purple - Slaves and Masters.log

Hi rocky,

I'm trying to build fre:ac by enzo1982 on OS X, which depends on libcdio-paranoia. I found homebrew only have cdparanoia package which is 12 years ago, and don't have libcdio-paranoia.

Would you please put libcdio-paranoia fomula into homebrew so it would be nice for dependation?

Thanks.

Given the libcdio reports C2 errors (with compatible units) can incorporate this feature to cd-paranoia?
The original library is not developed almost 8 years ago and has been progress in libcdio (and its integration with cd-paranoia, as the detection and ripping HTOA...)
The no use of C2 is the only feature that "becomes obsolete" to cdparanoia. In modern drives, they could be used even less aggressive mechanisms reading.
Thanks! Sorry for my english

Hello, I am using Gentoo and cannot compile from git source

 mrturcot  on GentooRig ~/stuff/github 
[ 02:49:18 AM ] ➜ git clone https://github.com/rocky/libcdio-paranoia
Cloning into 'libcdio-paranoia'...
remote: Enumerating objects: 1129, done.
remote: Counting objects: 100% (81/81), done.
remote: Compressing objects: 100% (49/49), done.
remote: Total 1129 (delta 29), reused 69 (delta 26), pack-reused 1048
Receiving objects: 100% (1129/1129), 2.33 MiB | 4.73 MiB/s, done.
Resolving deltas: 100% (728/728), done.
 mrturcot  on GentooRig ~/stuff/github 
[ 02:49:21 AM ] ➜ cd libcdio-paranoia
 mrturcot  on GentooRig ~/stuff/github/libcdio-paranoia on   master via  
[ 02:49:41 AM ] ➜ 
 mrturcot  on GentooRig ~/stuff/github/libcdio-paranoia on   master via  
[ 02:49:46 AM ] ❯ ./configure    
zsh: no such file or directory: ./configure
 mrturcot  on GentooRig ~/stuff/github/libcdio-paranoia on   master via  
[ 02:53:20 AM ] ❯ l   
Permissions Size User     Date Modified Name
drwxr-xr-x     - mrturcot 10 Sep 02:49  .
drwxr-xr-x     - mrturcot 10 Sep 02:49  ..
drwxr-xr-x     - mrturcot 10 Sep 02:49  .circleci
drwxr-xr-x     - mrturcot 10 Sep 02:49  .git
drwxr-xr-x     - mrturcot 10 Sep 02:49  doc
drwxr-xr-x     - mrturcot 10 Sep 02:49  example
drwxr-xr-x     - mrturcot 10 Sep 02:49  include
drwxr-xr-x     - mrturcot 10 Sep 02:49  lib
drwxr-xr-x     - mrturcot 10 Sep 02:49  m4
drwxr-xr-x     - mrturcot 10 Sep 02:49  src
drwxr-xr-x     - mrturcot 10 Sep 02:49  test
.rw-r--r--   581 mrturcot 10 Sep 02:49  .gitignore
.rw-r--r--   352 mrturcot 10 Sep 02:49  .travis.yml
.rw-r--r--   239 mrturcot 10 Sep 02:49  AUTHORS
.rwxr-xr-x   348 mrturcot 10 Sep 02:49  autogen.sh
.rw-r--r--   16k mrturcot 10 Sep 02:49  configure.ac
.rw-r--r--   35k mrturcot 10 Sep 02:49  COPYING
.rw-r--r--   16k mrturcot 10 Sep 02:49  INSTALL.md
.rw-r--r--   270 mrturcot 10 Sep 02:49  libcdio_cdda.pc.in
.rw-r--r--   274 mrturcot 10 Sep 02:49  libcdio_paranoia.pc.in
.rwxr-xr-x   701 mrturcot 10 Sep 02:49  make-check-filter.rb
.rw-r--r--  1.5k mrturcot 10 Sep 02:49  Makefile.am
.rw-r--r--  1.8k mrturcot 10 Sep 02:49  NEWS.md
.rw-r--r--   847 mrturcot 10 Sep 02:49  README.md
.rw-r--r--   407 mrturcot 10 Sep 02:49  THANKS

Are these the right steps? https://github.com/rocky/libcdio-paranoia/blob/master/INSTALL.md

I see there is "./configure.ac" but im not supposed to use that right?

Hello,

While updating the Debian package of libcdio-paranoia, I noticed lintian raised a bad-whatis-entry warning for /usr/share/man/man1/cd-paranoia.1.gz. Indeed, lexgrog cannot parse it:

% lexgrog -d /usr/share/man/man1/cd-paranoia.1.gz
...
record = 'cd-paranoia 9.8 (Paranoia release III via libcdio) - an audio CD reading utility which includes extra data verification features'
/usr/share/man/man1/cd-paranoia.1.gz: parse failed

I fixed the problem by changing this line to

@CDPARANOIA_NAME@ \- an audio CD reading utility which includes extra data verification features (Paranoia release III via libcdio)

(it seems there can be only the binary's name the man page is about before the \-)

This is a duplicate of a bug report I made an savannah. I don't know where the preferable place to report bugs for this project is, and wanted to get as wide coverage as possible.

https://savannah.gnu.org/bugs/index.php?49831

Hi, this may be dumb, but it would be nice to advertise this as the official repository for libcdio-paranoia (here in the readme but also on the website). It is extremely hard to find this repository starting from the official page and the fact that it is not hosted on savannah is quite intriguing. In fact the only link i could find was in this mail from 2012! This is quite confusing given the fact that the paranoia features and even API reference are advertised on the project's page.

I wanted to find out whether cdio_paranoia_read_limited accepts a NULL argument for the callback parameter. The check in this line...

I have problem with building gvs with libcdio-paranoia.
gvfs fails with:

gcc  -o daemon/gvfsd-cdda 'daemon/f77b12a@@gvfsd-cdda@exe/daemon-main.c.o' 'daemon/f77b12a@@gvfsd-cdda@exe/daemon-main-generic.c.o' 'daemon/f77b12a@@gvfsd-cdda@exe/gvfsbackendcdda.c.o' -Wl,--no-undefined -Wl,--as-needed -g -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto -Os -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto -fuse-linker-plugin -Wl,--start-group daemon/libgvfsdaemon.so common/libgvfscommon.so /usr/lib64/libgio-2.0.so /usr/lib64/libgobject-2.0.so /usr/lib64/libglib-2.0.so /usr/lib64/libgudev-1.0.so /usr/lib64/libcdio_paranoia.so /usr/lib64/libcdio.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/:$ORIGIN/../common' -Wl,-rpath-link,/home/tkloczko/rpmbuild/BUILD/gvfs-1.42.0/x86_64-redhat-linux-gnu/daemon -Wl,-rpath-link,/home/tkloczko/rpmbuild/BUILD/gvfs-1.42.0/x86_64-redhat-linux-gnu/common
/usr/bin/ld: /tmp/gvfsd-cdda.9RGuZe.ltrans0.ltrans.o: undefined reference to symbol 'cdio_cddap_track_audiop'
/usr/bin/ld: /usr/lib64//libcdio_cdda.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
error: Bad exit status from /var/tmp/rpm-tmp.rAf0WG (%build)

Just checked libcdio-paranoia tree and it is something strange about only that symbol

[tkloczko@barrel libcdio-paranoia-10.2+2.0.0]$ grep -r cdio_cddap_track_audiop
lib/cdda_interface/libcdio_cdda.sym:cdio_cddap_track_audiop
include/cdio/paranoia/cdda.h:extern int     cdio_cddap_track_audiop(cdrom_drive_t *d, track_t i_track);
include/cdio/paranoia/cdda.h:#define cdda_track_audiop       cdio_cddap_track_audiop

Looks like there is no actual code behind exactly that symbol.

May I ask for help or maybe it is a bug?

I wrote this mail to the cdparanoia-users list as a while ago:

https://marc.info/?l=cdparanoia&m=158566693027322&w=2

Hi,

I was wondering if anyone had any insight into limiting the amount of
re-reads and corrections cdparanoia will attempt to do for a single
sector (or at an even lower level). I find that for quite some CDs,
cdparanoia will try re-reading specific parts many, many times.

I've logged all the callbacks with --stderr-progress, mapped "cdframes"
to sectors to seconds of an audio CD, and for some parts, over 700000
correction() callbacks are issued for a single second (so 75 seconds).

Ripping a CD (in some cases) in it's entirety takes over 7 hours.
Ripping the same CD without any paranoia (-Z or -Y) will often finish
within minutes. Around the sectors that are problematic, the no-paranoid
mode will usually sound worse, and sometimes entire samples are gone.

So there is a clear advantage to using paranoia, but I can't help but
wonder if 7000000 reads and corrections are really required for a single
second of audio. Is there a way to set a cap on the amount of retries
for any given sector, so that I can attempt to strike a balance between
quality and time spent ripping? [1]

A sample breakdown of such a rip log looks like this [2] - 30 million
correction callbacks. Being able to impose an upper limit would likely
be helpful.

Regards,
Merlijn


[1] --never-skip=<number> doesn't seem to help here, since the drive is
not skipping, as far as I can tell.

[2] $ python breakdown.py ../5-legare-street-d3-t2/paranoid-1/log.txt
wrote 327631
finished 14
read 250191
verify 456005
jitter 101
correction 30109688
scratch 0
scratch repair 0
skip 160
drift 0
backoff 0
overlap 1526884
dropped 26
duped 29
transport error 0
cache error 0

Basically, I am interested in getting this in place for both libcdio-paranoia and cdparanoia.
Do you have any pointers / places to look?

Keep in mind that the above mail is written with cdparanoia in mind, not libcdio-cdparanoia, but I assume the same paranoia logic applies.

Drive: Samsung SH-S223L (flashed patched firmware years ago to remove DVD region code and riplock)

OS: Ubuntu 18.04 running in an LXC container due to avoid dependency problems on host, block device passthrough, this works.

CD tested: Mark O'Connor "Heros"

I use whipper to rip the CD's, but when testing the overread feature, after the last track of this disc, it would get stuck at ripping stage at 99%. I manually ran cd-paranoia with the same arguments as whipper used and it does rip the selected portion of the disc and then spits out "transport error" at the end.

Here was the command ran.

cd-paranoia --stderr-progress --sample-offset=6 --force-overread --force-cdrom-device /dev/sr0 14[00:00:00.00]-14[00:08:01.74] /tmp/tmpqeDioy.whipper.wav

If I remove the sample-offset there is no more transport error, but this imply anything useful?

Or is this whole issue implying my drive doesn't support --force-overread in the first place?

Thanks.

Hi,

After compiling libcdio-paranoia on Freebsd 12 make check fails halfway through with

[...]
Making check in data
make  cdda.bin        cdda.cue        cdda2.cue
'cdda.bin' is up to date.
'cdda.cue' is up to date.
'cdda2.cue' is up to date.
make[2]: don't know how to make CFLAGS. Stop
[...]

I did investigate a bit and the following is what I found:

• compiled using FreeBSDs make, not GNU make
• tested with (tag) release-10.2+2.0.0 and later. Error does not happen in tags before (offending line didn't exist)
• FreeBSD make doesn't support target specific variables

The offending code is on line 38 in test/Makefile.am:
check-am: get_libcdio_version

For FreeBSD 12 the following works for me:

.if target(get_libcdio_version)
       CFLAGS += @LIBCDIO_CFLAGS@
.endif

Using GNU make does work just fine. I'm not a real master in autoconf oder Makefile-ery, maybe the offending line could be written in a way that works with both make?

I'm working on a CD player program using libcdio-paranoia to read CD data and stream it to the sound card. I'm running into an issue where, for some discs only, the drive will continually oscillate between revving the disc to high speeds and spinning down, rather than spinning at a consistently low-ish speed. My drive reports that it does support setting its speed, but calls to cdio_cddap_speed_set return error code -405. I've tried adding a small sleep to my read thread (vs. reading as fast as possible until my buffer is full, then backing down) to even out the timing of the calls to cdio_paranoia_read_limited which also doesn't solve the issue. I've also tried setting retries to 0, so that reads will always be sequential.

Does anyone have insights into how to ensure the drive will run at a more constant speed?

Hullo,

I was updating the libcdio(-paranoia) packages in GNU Guix and noticed that the latest release here, 10.2+2.0.1, has yet to make it to https://ftp.gnu.org/pub/gnu/libcdio .

Would it be possible to upload an autoconf'd release tarball there?

These ‘archives’ that GitHub provides instead aren't very good: they're missing ./configure and change randomly, making them impossible to verify by hashes or signatures.

Thanks!

I've seen a number of people running into the same issue when using whopper (whipper-team/whipper#234), and one user going as far as just removing errors checks in the source code to force cd-paranoia to continue working (whipper-team/whipper#234 (comment)).

My hardware is HL-DT-ST GH22NS50, and in the AccurateRip database, it is expected that its read offset is +667. However, when using that number with cd-paranoia, it stops saying that the time/sector goes beyond end of my specified track:

$ cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:03:13.44] /tmp/tmpoEuyVd.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 2.0.0 x86_64-pc-linux-gnu
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

Time/sector offset goes beyond end of specified track.

However, Xiph's cdparanoia works ok:

$ cdparanoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:03:13.44] /tmp/tmpoEuyVd.track01.offset667.whipper.wav
Sending all callbacks to stderr for wrapper script
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector       1 (track  1 [0:00.00])
          to sector   14520 (track  1 [3:13.44])

outputting to /tmp/tmpoEuyVd.track01.offset667.whipper.wav

##: 0 [read] @ 25872
 (== PROGRESS == [>                             | ...... 00 ] == :^D . ==)   ##: 0 [read] @ 57624
 (== PROGRESS == [>                             | ...... 00 ] == :^D o ==)   ##: 0 [read] @ 89376
 (== PROGRESS == [>                             | ...... 00 ] == :^D 0 ==)   ##: 0 [read] @ 121128
 (== PROGRESS == [>                             | ...... 00 ] == :^D O ==)   ##: 0 [read] @ 152880
 (== PROGRESS == [>                             | ...... 00 ] == :^D 0 ==)   ##: 0 [read] @ 184632
##: 0 [read] @ 216384
 (== PROGRESS == [>                             | ...... 00 ] == :^D o ==)   ##: 0 [read] @ 248136
 (== PROGRESS == [>                             | ...... 00 ] == :^D . ==)   ##: 0 [read] @ 279888
 (== PROGRESS == [>                             | ...... 00 ] == :^D   ==)   ##: 0 [read] @ 311640
 (== PROGRESS == [>                             | ...... 00 ] == :^D . ==)   ##: 0 [read] @ 343392
##: 0 [read] @ 375144
##: 0 [read] @ 406896
...

And following the advice to leave out the time argument to cd-paranoia to guess, I end up with a very weird time signature indeed (but the sector number does match and the track is correctly ripped):

$ cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1 /tmp/tmpoEuyVd.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 2.0.0 x86_64-pc-linux-gnu
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

Ripping from sector       1 (track  1 [0:00.00])
          to sector   14520 (track  2 [0:00.-1])

outputting to /tmp/tmpoEuyVd.track01.offset667.whipper.wav

##: 0 [read] @ 21168
 (== PROGRESS == [>                             | ...... 00 ] == :^D . ==)   ##: 0 [read] @ 50568
 (== PROGRESS == [>                             | ...... 00 ] == :^D o ==)   ##: 0 [read] @ 79968
 (== PROGRESS == [>                             | ...... 00 ] == :^D 0 ==)   ##: 0 [read] @ 109368
##: 0 [read] @ 138768
 (== PROGRESS == [>                             | ...... 00 ] == :^D O ==)   ##: 0 [read] @ 168168
 (== PROGRESS == [>                             | ...... 00 ] == :^D 0 ==)   ##: 0 [read] @ 197568
 (== PROGRESS == [>                             | ...... 00 ] == :^D o ==)   ##: 0 [read] @ 226968
 (== PROGRESS == [>                             | ...... 00 ] == :^D . ==)   ##: 0 [read] @ 256368
...

Hi,
first of all, thanks for your work!
May you please create a new release so that the most recent changes are made available through the distributions.
For me especially #38 is interesting since I can't rip CDs at all without this fix.

Thanks! Fiete