Saturday, September 20, 2014

Extracting the mp3 From a Video


(In reference to a recent SFVLUG meeting....)

At the last meeting the question of how to extract an audio already in mp3 format from a video into a stand alone file came up.

I suggested something along the lines of

$ ffmpeg -i videofile -ac copy audiofile.mp3

making sure the output file has an extension of '.mp3', which is almost right but has an error.

It should be:

$ ffmpeg -i videofile -acodec copy audiofile.mp3

I mentioned mkvextract if the file was already matroska in the conversation. This actually implies another method of doing this, first convert to matroska with mkvmerge, then use mkvextract to dump the audio track:

$ mkvmerge -o intermediate_video.mkv videofile

$ mkvextract tracks intermediate_video.mkv 1:audiofile.mp3



$ rm -f intermediate_video.mkv

assuming, as typically happens, that track 1 of the matroska is the audio file. That probably should be verified, with

$ mkvmerge --identify intermediate_video.mkv

Yet another approach would be


$ mplayer -dumpaudio -dumpfile audiofile.mp3 videofile

Apparently mpv, an mplayer fork, does not currently support '--dumpaudio'. (To my suprise.)

Sunday, November 24, 2013

Undocumented scp



Recently I had need to set up some ssh keys and restrict their use to
only work with scp, not ssh in general.

After some fumbling around, I conducted some tests with no restrictions on the key
at the target remote host, with verbosity maximized with the local invocation of scp.
Scanning the output, there was mention of running 'scp -v -t ...' on the remote
system, which provided the key on how to do this.
With a bit of further testing, I found placing

command="/usr/bin/scp -v -t .../target/directory/"

in the options of the key involved in the ~/.ssh/aurthorized_keys
produced the desired effect.

Thinking I was probably not the only person to notice this, I googled
for "scp undocumented" and found references to '-d' and '-f' keys as well.

In the task of restricting ssh keys to only scp functionality there
seemed to be what I percieved as a lot of murkiness, with references
to a special 'scponly' shell etc., where an understanding of the
'-f' and '-t' keys would seem to be good for a lot of mileage.
Introducing other programs seems to introduce the possibility for
more bugs and confusion.
There is some mention of the '-f' and '-t' switches in O'Reilly's
SSH book, but not the man page.
("SSH, The Secure Shell: The Definitive Guide",
ISBN: 0-596-00011-1
Daniel J. Barrett and Richard E. Silverman
chapter 3.8.1, first edition 2001)

After some experiments, these are the guidelines I found for using
the '-t' and '-f' switches with cp in ~/.ssh/authorized_keys command="..." options.


1) Locally, everything after the ':', the user@host#port command line description of the remote
host, or ~/.ssh/config defined host parameters, is ignored.
This means you must specify the target directory or
file name in the remote hosts 'command=' option.
This may seem inflexible, but that is actually the goal of 'command=' options, to
reduce flexibility, and restrict the key to only desired effects.
Unless explicit, fully qualified directory paths are used,
directories are relative the home directory of the receiving user account.

2) '-t' ("To:")seems to closely parrallel the '-t' option in Gnu implimentations of 'cp' and
'mv' commands, but with scp you use it only in the remote 'command=' option.
It is used when the remote host is to recieve files.
If a file name is specified after '-t', it will be used literaly, so patterns
in this name are useless - they will only result in awkward file names that
use file matching metacharacters.
This also means that if a file name is specified, it will be overwritten each time
scp using the key is used, unless other actions have been taken
between invocations. Example:

command="/usr/bin/scp -v -t some/dir/".......

3) '-f' ("From:") is used when the remote host is sending files.
A pattern for a file name must be
appended to the directory specification. This pattern can be an explicit, particular file name.
To copy and entire directory, you would use '*', so:

command="/usr/bin/scp -v -f some/dir/*".....

4) If the desired effect is to recursively send a directory tree,
the '-r' switch must be used at both ends of the network connection, the simple invocation of
scp, and the 'command=' forced command.
When the remote host is recursively sending the tree, some pattern matching files
and directories must be part of the path specified in the 'command=' option.
This would most likely be '*' (dir/path/*).
When the remote host is receiving a recursively send directory tree, no file name
can be included 'command=' option, or on metacharacter garbage will result.
If you are sending directory trees recursively, it is likely you really want to
use rsync, but there may be obscure uses for this feature of scp.

5) I've yet to determine anything about the '-d' switch.

Dallas Legan,
dallas.legan@gmail.com
2013 Nov. 24

Monday, April 23, 2012

Rebirth?

I'm taking a break from the series on PDF handling,
for a bit, while reviving my blog.
Originally, I was going to post to thank Google for re-enabling support for Lynx some time back.
I'd noticed being able to log in with Lynx again after apparent Google
spokespersons had posted in various lists that they had gone through
their services and thrashed out various accessability/usability
issues.
But when I tried to log in tonight to actually post,
it had all evaporated.
No matter what obstructions Google places in the way of my posting,
the browser is only a tool to get to the point of running vi
to enter the actual content.
Maybe they will go back and clean up these obstructions
to browser choice. There is nothing intrinsicly graphical or
javascript necessary to edit a blog post, so maybe this will change.
I will be checking into submitting via e-mail to get past this.
d.e.l. 2012 Apr. 23
All that was last night.
Now, I'm posting with Lynx no problem, but there is a warning that
the old interface will be gone by the end of the month.
I'll see what happens. I'm not trying to bad mouth Google,
they are trying to balance somewhat conflicting goals,
but I'm confident they will find a way.
d.e.l. 2012 Apr. 23

Sunday, November 8, 2009

zgv'ing Again

When I started the series of posts on console tools for PDF files, I had another computer, and it handled graphics from the console differently. The chipset on the old computer was directly supported by SVGAlib and everything was working fine as far as I was concerned. When I upgraded to the current computer I found many of the graphics programs I was using needed to be shifted over to using frame buffer drivers or versions, as the video chipset on this PC seemed to be marginally (or in some instances brittly) supported in Linux. In some instances this was a gain, one example being w3m, which I can if so choosing run as a graphical web browser. In a couple of instances, zgv and svncviewer, I had to do without a console program and use an X program.

zgv is one of the more amazing graphic applications that run from the raw console in Linux. Perhaps even more amazing than watching videos in a naked command line interface. It is an image viewer that can be used on single images, slide shows, or a directory of image files, handling most of the formats we are familiar with. It has some simple image processing capabilities, and when navigating a directory of images, can generate thumbnails of all the images and can present a graphical navigation interface with these thumbnails. The alternate viewer 'fbi' (Frame Buffer Imageviewer) if fine, but to date simply lacks some of the many capabilities of zgv. I first encountered zgv as a default image viewer for text browsers such as Lynx and w3m.

It's been over a year since I got the new computer, and the other morning, I decided to try to see if there was some way to revive use of zgv. It never failed to run, but in maybe half the images colors were distorted beyond reasonable use - something like solarization of color phototgraphic film - great if you want an LSD/Timothy Leary effect but not for daily use.

In the SVGAlib configuration file, I'd hardcoded use of the framebuffer driver (as opposed to SVGAlib choosing one of the supported chipsets) by uncommenting the line:


chipset FBDEV           # Use kernel fbdev, instead of direct hardware.

in the file /etc/vga/libvga.config. With this, applications that use SVGAlib will now indirectly use the video framebuffer. I rummaged around a bit through the zgv man pages, trying various things. One clue I searched on to see if there was something that might get it working consistently was the word 'force'. My notion was that perhaps something was being misinterpreted by the program and it 'forcing' some initial condition might solve the problem. I finally found a switch '--force-viewer-8bit' (or briefly '-j') that seems to do the trick. No solarization effects. It may be that some images could be displayed with greater sharpness or color accuracy, '8bit' throwing away parts of 16/24 bits of pixel information, but everything *looks* reasonable. Nothing is reduced to psychedelic poster (or even comicbook) appearence. The worst thing I've encountered so far is that after looking at information on the image file sometimes I need to refresh the display with a CTL-L or CTL-R, but this is a minor point. To make this default behaviour, edit the file /etc/zgv.conf and add the line:

force-viewer-8bit on

A few other settings I include in the file (you can look them up in the man page) are:

zoom on
centre on
auto-mode-fit on
jpeg-speed 1
mousescale 2.0
mouse on
block-cursor on
fs-perfect-cols on
jpeg-index-style 3
fs-thick-text on

A couple that apparently must be left out of the configuration file and placed among command line switches are:

#  show-dimensions on
# reload-delay 1000000
#   - fatal in this file

A few of the more important commands of zgv:

?        -  help
ESC      -  return to previous mode (eventually exiting)
Enter    -  go to the next image
v        -  toggle file selector mode between graphical or text
/        -  help for video modes available
:        -  display file information
;        -  reset brightness/contract/etc. to default
Alt-u    -  generate/update thumbnail images
Ctrl-I   -  start a slide show of files tagged in file selector mode.
Ctrl-R   -  refresh view/directory
Ctrl-L   -  refresh view/directory
Right Mouse button  -  context sensitive menu
Left  Mouse button  -  select an image or directory in file selector/directory view mode

You can navigate the file selector or large images with cursor, vi or (what I think are) WordStar keys. I leave exploring the various zooming, rotating, mirroring, flipping, contrast, brightness, gamma, rendering and file tagging capabilities to you, the reader. The ironic reality is that using this as the viewer for a text mode web browser, the surfer has more control over image viewing than any I've encountered with so called graphical web browsers.

A few of the command line switches can be of use. The '--reload-delay 100000' mentioned above effectively sets the default slide show interval to totally at the users decision to move on, instead of the default 4-sec. '--show-dimensions' (or -s) causes zgv to print the dimensions of displayed files to standard out, perhaps to pass on to some program for image processing. '-T' causes zgv to print the names of tagged files to standard out, where they could (for instance) be passed on via a script to CUPS and printed out, or copied/moved to a holding directory. And this really is the tie-in with these article with on .pdf. After using ghostscript to convert the pages of a pdf document to images, you can browse through them with zgv in file selector mode, tag some, and have them printed out.

Friday, October 2, 2009

With bmv ...

When I first started this series of posts on command line access to pdf files I had a different computer, one that was pretty compatible with SVGALib tools. The newer computer seems to work with SVGALib with extreme unpredictability. There seems to be decision 'out there' to not bother with keeping SVGALib current, to try and shift things towards use of frame buffers, which seem to work fine on the new PC> A while back I became aware of a frame buffer based tool for viewing postscript files called bmv. To take advantage of in pdfmenu, I added some lines:
alias PDFTOPS='/usr/bin/pdftops  '  ;
alias BMV='/usr/bin/bmv -m1 -v13 '  ;
    #       the -m/-v values were tuned by tests to what seemed
    #       to work best on my computer for typical .pdf files.
..........
 10 )
    THEPSFILE="${INSIDEFILE#/tmp/}"  ;
    THEPSFILE="/tmp/${THEPSFILE%.pdf}.ps"  ;
    RM  ${THEPSFILE}  ;
    PDFTOPS  ${INSIDEFILE}   ${THEPSFILE}  ;
    BMV      ${THEPSFILE}  ;
    RM ${THEPSFILE}  ;
    ;;
  
and appropriate entries to the select menu. bmv is fairly easy to figure out how to navigate. In general, I'm satisfied with it's job of showing .pdf files.

Monday, January 19, 2009

pdfmenu

As you may have figured out by now, I created a master script for handling pdf files when in text consoles. I've put this up at http://www.lafn.org/~aw585/pdfmenu. There are probably many improvements that can be made to this but it provides a simple way to attack pdf files.

firefox -new-tab ......

I used to use one of my 26 bookmark files of Lynx to pass URLs from web browseing in Lynx to Firefox. I had that particular file bookmarked by Firefox, and could simply bookmark a url to the "F" bookmarkfile from Lynx, then when I swapped to Firefox pull up that file from Firefox's bookmarks, then seek out the particular URL in question. I thought that was pretty slick, saving a lot of scratch paper moving the URL from a text console to GUI environment, but I've since done better.

Looking over the man page for Firefox, I found there was provision for sending URL's to already running instances of 'fox. After a bit of experimentation, I found that this could be done from text consoles, and was not restricted to being issued from the GUI environment. With this information, I added these lines to my Lynx externals in /etc/lynx-cur/lynx.cfg:

EXTERNAL:http:firefox -new-tab %s --display=\:0.0 ; sudo chvt 11 :TRUE

EXTERNAL:http:firefox -new-window %s --display=\:0.0 ; sudo chvt 11 :TRUE

The '-new-tab' and '-new-window' switches are pretty self explanatory. --display tells which X display to use, which could is theory be more complex than most people use. It should be pointed out that it was necessary to escape the colons with this parameter so as not to confuse Lynx. The part starting with 'sudo ...' might be unfamiliar to some. chvt is a command to switch to other virtual consoles. Currently it seems to be limited to those setup by inittab or it's equivalent, and requires root privilages to function. I've sudo configured to run it without needing any password. Anyway, one curious thing is that it can switch you to your GUI, which in my case is console 11 - you'd need to adjust it to your situation, usually console 7.

I'm putting this article in my series on handling pdf files in text consoles because you can use this to pass the location of a file to Firefox from a console and let it handle the file however you have Firefox configured to. The fact of the matter is though that almost any thing can easily be passed from Lynx to Firefox this way not just pdf files. This has accessability implications in that someone who may out of neccessity use Lynx can with this use Firefox as a simplified interface to running various media types in the GUI environment. They could have their GUI configured to automaticly launch FireFox when it starts, and perhaps set things up so that when finished the switch back to the console and restart X rather than bother trying to navigate the GUI. This is pretty crude, but it might serve their needs. One complication might be the need to locate a start button, such as sites like YouTube have, but perhaps even this might be overcome. Anyway only the future will tell.