Announcement

Collapse
No announcement yet.

KDE Applications 19.04 To Support eBook Thumbnails, Allow Ripping CDs To Opus

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • KDE Applications 19.04 To Support eBook Thumbnails, Allow Ripping CDs To Opus

    Phoronix: KDE Applications 19.04 To Support eBook Thumbnails, Allow Ripping CDs To Opus

    With the feature freeze for KDE Applications 19.04 happening next month in order to meet the planned 18 April release date, KDE developers are busy getting their new features ready and reviewed for this next round of application updates...

    http://www.phoronix.com/scan.php?pag...04-CDs-To-Opus

  • #2
    Last time I ripped a CD it shattered into a few sharp pieces and I cut myself.

    Just kidding, it was Dimmu Borgir's self-titled to FLAC. From there, the FLAC became Opus.

    Comment


    • #3
      Originally posted by skeevy420 View Post
      Last time I ripped a CD it shattered into a few sharp pieces and I cut myself.

      Just kidding, it was Dimmu Borgir's self-titled to FLAC. From there, the FLAC became Opus.
      What tool do you use? These days, I use whipper, a fork of morituri, which is the closest Linux analogue to Exact Audio Copy, verification-wise.

      Comment


      • #4
        Originally posted by ssokolow View Post

        What tool do you use? These days, I use whipper, a fork of morituri, which is the closest Linux analogue to Exact Audio Copy, verification-wise.
        Plain ole K3B. Whipper looks interesting. I'll have to remember to try that the next time I go to rip some audio.

        Comment


        • #5
          cdparanoia, it works; you can encode from there with GNU parallel and the flac encoder, add your tags to the FLAC however you choose (maybe you like EasyTag), maybe add loudness information with a R128/BS.1770 scanner, and from there anything you transcode to will be good.

          Comment


          • #6
            ripperX

            Anyways, I don't expect opus to significantly beat vorbis (.ogg) at higher bitrates. However it makes a really interesting option for audiobooks. You could rip at 30-50 kbps without completely obliterating music and sound effects like speex does.

            Comment


            • #7
              KIO plugin for ripping CDs into OPUS? Meanwhile a 15 year old KIO bug left in the dark https://bugs.kde.org/show_bug.cgi?id=75324, it is 2019 and KDE cannot handle smb:// mount points (and alike) in sane way, on top of that there's 95% performance degradation in transfer speeds in some cases -- that is if you find a KIO aware KApp that can accomplish what you're trying to do. GVFS rules and leaves KDE in the dust in this category.

              Comment


              • #8
                Originally posted by microcode View Post
                cdparanoia, it works; you can encode from there with GNU parallel and the flac encoder, add your tags to the FLAC however you choose (maybe you like EasyTag), maybe add loudness information with a R128/BS.1770 scanner, and from there anything you transcode to will be good.
                Whipper sits on top of cdparanoia and adds extra verification, such as:
                • Refusing to rip anything if there's no result on file from running cdparanoia's drive calibration (Normally, cdparanoia just operates on default settings)
                • Detecting "Hidden Track-One Audio" and ripping it too (some CDs hide easter eggs if you start track 1 playing, then seek backwards to before 0:00)
                • EAC's "rip the track up to 5 times and only declare success when two attempts produce identical data" behaviour to work around the helpfulness of error-correction in CD/DVD/BluRay drive firmware
                • Support for checking the result against the AccurateRip database. (Though not submitting to it. That can only be done via a closed-source Windows DLL.)
                • Tagging ripped tracks using MusicBrainz, which produces much more reliable results than CDDB-style things like FreeDB because it operates on a disc-identification system more reliable than the collision-prone "list of track lengths" system that CDDB-style things use.
                EAC does all of these and more (there have been a couple of discs that I had to rip in EAC under Wine because they were particularly degraded in ways that EAC's "retry sector-by-sector" behaviour was better at recovering than the cdparanoia-based "retry track-by-track", but, for the most part, it worked out well.)

                Admittedly, I think EAC gave up and said "good enough" with the degraded ones , but I couldn't hear anything wrong with the rips and, since they were free from the leftovers of a church sale, I'm not going to spend money on a whole new PATA drive just to work around the problem sectors.
                Last edited by ssokolow; 02-11-2019, 08:36 AM.

                Comment


                • #9
                  Originally posted by hax0r View Post
                  KIO plugin for ripping CDs into OPUS? Meanwhile a 15 year old KIO bug left in the dark https://bugs.kde.org/show_bug.cgi?id=75324, it is 2019 and KDE cannot handle smb:// mount points (and alike) in sane way, on top of that there's 95% performance degradation in transfer speeds in some cases -- that is if you find a KIO aware KApp that can accomplish what you're trying to do. GVFS rules and leaves KDE in the dust in this category.
                  in b4 the usual "but people have different interests, therefore they only work on the things that interest them"

                  Comment


                  • #10
                    Originally posted by hax0r View Post
                    KIO plugin for ripping CDs into OPUS? Meanwhile a 15 year old KIO bug left in the dark https://bugs.kde.org/show_bug.cgi?id=75324, it is 2019 and KDE cannot handle smb:// mount points (and alike) in sane way, on top of that there's 95% performance degradation in transfer speeds in some cases -- that is if you find a KIO aware KApp that can accomplish what you're trying to do. GVFS rules and leaves KDE in the dust in this category.
                    Yes, I have this feeling sometimes as well... there are plenty of bugs that deserve more attention, especially instabilities or limited workflows. But these many changes that are happening in the KDE world are a good sign. People develop what they are interested in, so from this perspective I welcome all the new features and it is nice to read about them even if they mostly do not affect me. A community that is constantly improving like this, certainly attracts new developers and by this increasing the chance that other bugs get addressed too :-)

                    Comment

                    Working...
                    X