Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
TOC
1 - what i'm doing
2 - what i tried
3 - questions
WHAT I'M DOING
I'm continuing my work trying to identify efficiencies and lack thereof in the linux CLI vs GUI
The main problem i have at the moment (well it isn't a problem it's actually a good thing in terms of the work i have done) is that i need to verify something.
I've compared ripping and compressing audio to mp3 (if you come back with ogg, that's fine too), and found (what i had hoped to find) that the GUI is faster (marginally, under assumptions i had though would be a rather unfair) by less than a second (in terms of user input).
Anyway, the KDE thing was straight forward, services, copy, paste, done.
I looked at GRIP, but ... yeah it works but in terms of modelling isn't the fastest, and didn't seem to work 100%, besides KDE's works fine.
WHAT I TRIED
I ripped a track in KDE, and ended up getting the proper filename and id3 tag automatically. That is (obviously) a great thing, BUT this is also the problem, IF the command line is incapable (as in no program exists that is easy to use) of using freedb data, Then CLI looses (which means i don't have to model ANOTHER task ... CLI is prooving too damn efficient [in mathematical terms]). IF CLI can access this info, or i can make the sequence more efficient, CLI wins (and then i have to go away from straight forward time estimates (some values of which are potentially dated) or model more tasks (which is slow and tedious). Regardless here is how i did the command line rip:
cdparanoia 1
lame -m s -q 0 --cbr -b 192 cdda.wav <trackname assumed at 20 char>.mp3
QUESTIONS
SO to summarize what i would like to know:
1) can any command line ripper+encoder access freedb data?
2) can lame be preconfigured (by config file, i had a look at the source code, and yes changing that is reasonably straight forward it seemed, but that is hardly in the sphere of average user, and no a wrapper script is not acceptable)
3) i tried piping :
cdparanoia 1 | lame - - > track1.mp3
which didn't work out well (at all, i thought it had, but i couldn't replicate using the data i'd written down, or that was in the history on the same album ... so i think i was listening to something else). Is piping possible, or is there a program that does both in one go
I'm continuing my work trying to identify efficiencies and lack thereof in the linux CLI vs GUI
Big ambitions. I'd advise you to learn more about the command-line before doing something like this. Also, why are wrapper scripts not acceptable? They are the heart of the CLI. Aren't you biasing your study against CLI then?
Now that this is done, save this as a script and run it with the track number as argument. You cannot say that a script is unfair, as the GUI is essentially this. Everything is done. Here, once this script is done, I don't ever have to worry about it not working (I know, I know, some exit codes have to be checked).
Again, it's not at all difficult to name the mp3 file whatever you want it to be, using the variables.
Oh, by the way, I was assuming that you cannot install any new apps (like Abcde, which was suggested by DavidPhillips) as you said that you were checking the efficiency ...
If you can install stuff, then, Abcde seems like a brilliant suggestion. I'm not sure whether it supports freedb.
... i'm struggling with the wrapper argument ... yes it is a command line power, but i don't know if writting a wrapper is fair, i mean if writting a wrapper is fair, then i might as well change the lame sourcecode, so by default it encodes at VBR 192-320 in q0 v0 in true stereo. or add a button to the KDE quicklauncher which rips a cd.
Yes you can customize the CLI to high heavens, i mean i could bind the entire task to rcd 1 ,and then it rips track1 and encodes it, and does everything i want it to, but i can't set an experiment where i tell the person rip track one and encode it by typing "rcd 1", then click that button ...
It becomes meaningless once you leave the software behind as 95% of normal users would use it. But then the question arrises do 95% of normal users really use it the way we think?
Thank you for that refute... i may have to talk to my research supervisor ...
I'm not telling you to change the sources of anything. The way anything is done in the CLI is through commands (that's why it has such a name). Just because I write a script, it does not mean that I'm doing anything special.
I just mentioned that it would be unfair to compare how you do particular tasks in a GUI and CLI. Some tasks are better suited for CLI and some not. Some of us find the CLI a much better thing, as it gives so much power. That power, if it can be handled, is an awesome thing. It can do things no GUI can, without having to write a whole new program.
It's a different paradigm. It's a different way of thinking. Many GUI apps have (well, not exactly) a functionality which is the same as a few shell commands thrown together. Just because everything's done for you in the GUI, you cannot argue that the CLI is "inefficient".
It's assumed that you know what you're doing and know how to get it done. If you're doing something for the first time, you can write a throwaway script. If you're going to be using it often, make it a proper script. That's the way things work in the CLI field. It does compromise ease of use for power and flexibility. But, the power is just what some of us are looking for.
On the other hand, the GUI is well suited for applications like web browsing and image editing and so on. I couldn't live without Mozilla and Gimp.
In conclusion, if you're looking at "95% of the people", CLI's the wrong place to be looking. It's almost final that CLI is not for the weak-hearted. If you write scripts to do what the users want, then, CLI is almost indistinguishable from the GUI (you'd type a command here, and you'd click a button there. A touch typist can do both in about the same time. Sometimes the CLI is faster in that you don't have to use the mouse to find a button.)
david@zeus:~> abcde
Getting CD track info... Grabbing entire CD - tracks: 01 02 03 04 05 06 07 08 09 10
Retrieving 1 CDDB match...done.
---- George Strait / Carrying Your Love With Me ----
1: Round About Way
2: Carrying Your Love With Me
3: One Night At A Time
4: She'll Leave You With A Smile
5: Won't You Come Home (And Talk To A Stranger)
6: Today My World Slipped Away
7: I've Got A Funny Feeling
8: The Nerve
9: That's Me (Every Chance I Get)
10: A Real Good Place To Start
Edit selected CDDB data? [y/n] (n):
Is the CD multi-artist? [y/n] (n):
Grabbing track 01: Round About Way...
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty@xiph.org> and Xiphophorus
Report bugs to paranoia@xiph.orghttp://www.xiph.org/paranoia/
Ripping from sector 0 (track 1 [0:00.00])
to sector 13929 (track 1 [3:05.54])
outputting to /home/david/abcde.7a07d90a/track01.wav
(== PROGRESS == [ > 0| 001839 00 ] == :-) 0 ==)
Done.
Grabbing track 02: Carrying Your Love With Me...
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty@xiph.org> and Xiphophorus
Report bugs to paranoia@xiph.orghttp://www.xiph.org/paranoia/
Ripping from sector 13930 (track 2 [0:00.00])
to sector 31361 (track 2 [3:52.31])
outputting to /home/david/abcde.7a07d90a/track02.wav
(== PROGRESS == [ + *| 031361 00 ] == :^D * ==)
Done.
etc...
etc...
etc...
Code:
Tagging track 04 of 10: She'll Leave You With A Smile...
Encoding track 05 of 10: Won't You Come Home (And Talk To A Stranger)...
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 17249 Hz - 17782 Hz
Encoding /home/david/abcde.7a07d90a/track05.wav
to /home/david/abcde.7a07d90a/track05.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
6563/6565 (100%)| 0:24/ 0:24| 0:29/ 0:29| 7.0639x| 0:00
average: 128.0 kbps LR: 5 (0.07615%) MS: 6561 (99.92%)
Writing LAME Tag...done
ReplayGain: -5.1dB
Tagging track 05 of 10: Won't You Come Home (And Talk To A Stranger)...
Encoding track 06 of 10: Today My World Slipped Away...
LAME version 3.95 MMX (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE, SSE2
Using polyphase lowpass filter, transition band: 17249 Hz - 17782 Hz
Encoding /home/david/abcde.7a07d90a/track06.wav
to /home/david/abcde.7a07d90a/track06.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
7454/7456 (100%)| 0:28/ 0:28| 0:31/ 0:31| 6.9492x| 0:00
average: 128.0 kbps LR: 571 (7.657%) MS: 6886 (92.34%)
Writing LAME Tag...done
ReplayGain: -4.1dB
etc...
etc...
etc...
Code:
Tagging track 10 of 10: A Real Good Place To Start...
Finished.
The resulting files...
Code:
david@zeus:~> ls -R ~/Rip
/home/david/Rip:
George Strait
/home/david/Rip/George Strait:
Carrying Your Love With Me
/home/david/Rip/George Strait/Carrying Your Love With Me:
A Real Good Place To Start.mp3 Shell Leave You With A Smile.mp3
Carrying Your Love With Me.mp3 Thats Me (Every Chance I Get).mp3
Ive Got A Funny Feeling.mp3 The Nerve.mp3
One Night At A Time.mp3 Today My World Slipped Away.mp3
Round About Way.mp3 Wont You Come Home (And Talk To A Stranger).mp3
Last edited by DavidPhillips; 06-26-2004 at 05:54 PM.
arvind_sv: don't get me wrong please, i agree completely with what you are saying, but trust me that what you are saying is not new to me. You have to understand that what i am doing is academic research (not an assignment, a thesis), with the aim to find a why and how, rather than doing a comparison. Sort of like Object Design. You want your object to accept the data, do it's thing, tell you the outcome. Same with what we are trying to find here, you have a task, the task has characteristics, hence it is suitable to CLI / GUI. I finished a number of simulations today, (mathematical models), which overall i found suprising, and time efficiency is clearly NOT the only thing to look at (which i had in my immaturity hoped).
Quit right GUI is suitable to drawing, but ... that's not a GUI or CLI issue. In reality it is a question of Direct Manipulation. Drawing programs are pointer driven, ie you manipulate the pointer, the keyboard is not suited to this, but it isn't an issue of commands it's an issue of a mouse being suited to the metaphor that is "paint brush" (well, better than a keyboard anyway, but not as good as a graphics tablet).
Web access on the otherhand (as in html) is on the otherhand a GUI task, because HTML is generally used with images, and as such, lynx is not suited to displaying HTML because ... it doesn't do images. That doesn't make lynx a poor browser for every job. Consider this: man ... i always look up man pages on the console, never in the GUI ... don't know why, i just don't. The task is very similar to web browsing, but the information changes.
Please don't think i'm dismissing what you said, i think it is very true, and i think it is very important, but i'm looking at the situation from a different angle.
Source code modification, wrapper scripts and config files, or using software as it comes ... well it is something more familiar to you than me, i agree, i'm not all that when it comes to scripts, i prefer Java or Assembly language (worlds appart, i know).
But i digress, the concern of the overall research is NOT gui vs cli, no, it is gui AND cli vs gui ONLY. I believe that CLI has alot to offer, but... what that is i can only find out by means of comparing the two against each other.
David : wow thanks you created more work for me, BUT that's all good, i'll need to model this
Please don't think i'm dismissing what you said, i think it is very true, and i think it is very important, but i'm looking at the situation from a different angle.
Fair enough. Don't worry. I'm not going to take it the wrong way or anything. I just thought I could help. If I could, then, it's fine. If I could not, then, that's ok too.
Oh no, you helped tremedously, you gave me a lot of things to think about, because you are echoing exactly what people would picking up the thesis, so your remarks ARE important and i am thankful.
In fact since David threw out one of my task models (well i'm about to model that now) odds are i will consider what you said once again regarding web-browsing.
Honestly, don't believe i want to be or am dismissive.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.