IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Musepack SV8 mpcenc CD-Ripper for Linux !
Terrorizer
post Oct 19 2010, 01:43
Post #1





Group: Members
Posts: 5
Joined: 19-October 10
Member No.: 84711



Hi @all,

...I'm searching for a CD-Ripper under Ubuntu (10.10) who can handle the mpcenc-SV8-Encoder !!!
In the past (Ubuntu 10.04) I've used Grip and all works perfect, but now with 10.10 it is not possible to install Grip...and the follow-up tool MP3Mesa don't run with my mpcenc commandline: --insane --artist "%a" --title "%t" --album "%g" --year "%y" --track "%n"

Can somebody help me please or is this cmd-line a failure ???


Cya, Terrorizer !!!
Go to the top of the page
+Quote Post
shadowking
post Oct 20 2010, 00:47
Post #2





Group: Members
Posts: 1523
Joined: 31-January 04
Member No.: 11664



You can probably build a binary from the source package :

http://packages.ubuntu.com/source/jaunty/grip

- apt-get all the -dev packages (everything in red) and the build-essential package

- Download the source: .diff, tar.gz, .dsc to your home folder

dpkg-source -x *.dsc
cd *
dpkg-buildpackage -us -uc
sudo dpkg -i *.deb



--------------------
Wavpack -b450
Go to the top of the page
+Quote Post
Terrorizer
post Oct 20 2010, 16:23
Post #3





Group: Members
Posts: 5
Joined: 19-October 10
Member No.: 84711



...thanx, Grip runs now but ripping with mpcenc (SV8) still dosn't work !!! ...any idea ???
I tried also mppenc (SV7) and this also fails...in 10.04 i did completely the same & everythings runs good and now nothing !!!

This post has been edited by greynol: Oct 27 2010, 01:25
Reason for edit: Removed unnecessary full-quotation of the previous post.
Go to the top of the page
+Quote Post
shadowking
post Oct 21 2010, 01:35
Post #4





Group: Members
Posts: 1523
Joined: 31-January 04
Member No.: 11664



Run it from the commandline and see if any errors show up.


--------------------
Wavpack -b450
Go to the top of the page
+Quote Post
Takla
post Oct 21 2010, 16:54
Post #5





Group: Members
Posts: 169
Joined: 14-November 09
Member No.: 74931



In Debian the SV8 version of musepack is included in testing/squeeze, the package name is musepack-tools. If you're happy to use a command line ripper then ripit supports SV8 just fine, and also supports the older version if you prefer it. I'm not sure I ever encoded anything using musepack before but I just tried it with ripit and it worked fine; the CD audio was securely ripped, encoded to mpc, named and tagged, and replaygain automatically applied using mpcgain. It sounds great... just like my mp3s, oggs and flacs of the same CD :-)


CODE
$ mpcdec -i 01\ -\ John\ Paul\ Jones\:\ So\ ell\ encina.mpc
mpcdec - Musepack (MPC) decoder v1.0.0 (C) 2006-2009 MDT
Built May 31 2010 16:23:03
file: 01 - John Paul Jones: So ell encina.mpc
stream version 8
encoder: --Stable-- 1.30.1
profile: 'Standard' (q=5.00)
PNS: off
mid/side stereo: on
gapless: on
average bitrate:  170.9 kbps
samplerate: 44100 Hz
channels: 2
length: 3:51 (10197684 samples)
file size: 4940364 Bytes
track peak: 84.88 dB
track gain: 60.20 dB / 4.62 dB
album peak: 89.38 dB
album gain: 58.38 dB / 6.44 dB


One thing that doesn't seem possible when using ripit with musepack (compared to using ripit with ogg vorbis, flac, lame mp3) is that it doesn't automatically embed cover art in the tags. I believe mpc files use APE tags. I'm not sure if there are tools in Ubuntu or Debian which can add album art to files using APE. There may well be but I don't know what they are, perhaps someone else can offer some info.

Unfortunately for Ubuntu users some of the stuff in universe and multiverse seems to be gathering dust and collecting cobwebs. For suitable binary packages of musepack-tools and ripit I think you'll need to try out the packages from Debian testing (no guarantee they will work in Ubuntu) or build them yourself from source. For ripit you need at least version 3.8.3, but the recent stable 3.9.0 is preferable. If your drive passes the cdparanoia analysis `cdparanoia -A` and you know the read offset then you will be all set. If your drive doesn't pass the analysis and you don't know the read offset you won't be any worse off than when using grip ;-)

edit:typo(s)

This post has been edited by Takla: Oct 21 2010, 16:55
Go to the top of the page
+Quote Post
Terrorizer
post Oct 22 2010, 15:23
Post #6





Group: Members
Posts: 5
Joined: 19-October 10
Member No.: 84711



...many thanx for this tip...i will try ripit today...and now i must work me through all those -options of ripit !!!

This post has been edited by greynol: Oct 27 2010, 01:27
Reason for edit: Removed unnecessary full-quotation of the previous post.
Go to the top of the page
+Quote Post
Takla
post Oct 22 2010, 16:10
Post #7





Group: Members
Posts: 169
Joined: 14-November 09
Member No.: 74931



QUOTE (Terrorizer @ Oct 22 2010, 14:23) *
...many thanx for this tip...i will try ripit today...and now i must work me through all those -options of ripit !!!


The easiest way to use ripit is not to construct a long series of options on the command line but to copy /etc/ripit/config to ~/.ripit/config and then edit ~/.ripit/config. It is well commented and mostly self explanatory (if there are options you don't understand then leave them as they are). Then to rip, encode, name, tag, playlist etc all you need to do is enter the command 'ripit'. Open the config file in a text editor which supports syntax highlighting and you'll more easily appreciate the simplicity.

For what it's worth if I wanted to use ripit with musepack then the musepack specific parts of the config file look like this:

coder=5
musenc=mpcenc
quamuse=5
museopt=
mpcgain=mpcgain

Line by line that is:

choose musepack encoder
choose SV8 version (old version would be mppenc, this is described in the ripit config comments)
musepack quality 5 (equivalent to --standard or --quality 5.00)
?? I think museopt is mostly for options relevant to the older musepack, not the new one. I left it blank.
'mpcgain=' means no replaygain is applied. If as above then album gain applied.

If you know your drive read offset and think it matters then you can add that to the ripopt line. My Hitachi drive has a read offset of +667, so

ripopt=-O 667

That's a cdparanoia option and this assumes you didn't doing anything odd like change the default ripper from cdparanoia to something else.

The other rip options such as paranoia, prepend, extend etc should be left at default unless you have some good reason to change them.

All the options referring to other encoders can be ignored. You can set your preferred naming scheme, output directory and so on. If you're doing a batch you can set

interaction=0
eject=1
loop=1

and ripit will keep on ripping and encoding without intervention as long as you keep feeding it another CD when the last one auto ejects. Of course the naming and tagging will only be as good as whatever is out there at freedb or musicbrainz so eventually you probably have to get involved if only to check the names/tags but it does make for a neat automated process. If you choose interaction=1 then you get offered the chance to check/edit the info collected from freedb/musicbrainz.





Go to the top of the page
+Quote Post
Terrorizer
post Oct 26 2010, 23:52
Post #8





Group: Members
Posts: 5
Joined: 19-October 10
Member No.: 84711



...many, many thanx Takia, very useful tip, until yet it seems that this is the only tool (beside ABCDE) who can handle mpcenc SV8 [...only commandline, but very practicable]

PS.: is it possible, that the [ripopt=-O 667] - option only works with enabled cdparanoia, because i disabled it with [paranoia=0] for faster ripping ???

Cya, Terrorizer !!!

This post has been edited by greynol: Oct 27 2010, 01:27
Reason for edit: Removed unnecessary full-quotation of the previous post. Please be considerate of others who are forced to scroll past something they've already read or can access higher up in the discussion.
Go to the top of the page
+Quote Post
Takla
post Oct 27 2010, 01:13
Post #9





Group: Members
Posts: 169
Joined: 14-November 09
Member No.: 74931



There's no point setting the offset if you disable paranoia. The value 667 is specific to certain drives anyway. If you wanted to set the offset you would need to discover your particular model's read offset and use that. It's extremely unlikely to ever make a difference to what you hear. Essentially it's a form of calibration (not correction) so that the results from different physical drives can be easily compared. And according to the cdparanoia man page:
QUOTE
-O --sample-offset number
Note that this will cause
cdparanoia to attempt to read partial sectors before or past the known user data area of the disc, probably
causing read errors on most drives and possibly even hard lockups on some buggy hardware.

So set it up if it's helpful, and of course check the output of cdparanoia and ensure your drive can deal with it, but if you don't have a need for it or your drive freaks out trying to read sectors it in fact can't access then don't use a read offset and don't worry about it.

Obviously it's your choice but I'd suggest not disabling paranoia. Cdparanoia is fast even with paranoia enabled (unless your CD is in very poor condition) and without paranoia enabled you definitely will get, sooner or later, audible artefacts due to scratches/dirt or even just read errors caused by very low quality original media.

This post has been edited by Takla: Oct 27 2010, 01:14
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 26th July 2014 - 12:10