Computing desk
< March 30	<< Feb \| March \| Apr >>	April 1 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

March 31

downloading a podcast

Hi, I've been interviewed & want to keep/ record the podcast. The link opens into a kind of pdf that says download but turns out to be an archive to that url. Is there any way to do this for personal use only? I have a MacBook Pro. Thanks, Manytexts (talk) 04:55, 31 March 2012 (UTC)[reply]

Looks like it's not a free podcast for download so probably illegal. Sorry, Manytexts (talk) 05:08, 31 March 2012 (UTC)[reply]

I would contact the person/organisation that interviewed you and ask if you could have a copy - I would imagine most organisations would be happy to give you a recording and in any case it can't hurt to ask. Equisetum (talk | contributions) 09:42, 31 March 2012 (UTC)[reply]

Indeed. A local TV station gives out DVDs of interviews to members of the community that they interview on their news show. They may be happy to give you an MP3 of the interview as long as you promise to use it only for personal use. Dismas|^(talk) 14:42, 1 April 2012 (UTC)[reply]

Half/Fullwidth

What is the point of halfwidth and fullwidth letters, and why are they only available for Latin, CJK punctuation, Katakana, and Hangul Jamo? Inter change able|talk to me 17:18, 31 March 2012 (UTC)[reply]

See halfwidth and fullwidth forms. Back when computers usually ran in text mode, there was one byte controlling each character cell on the screen. One byte wasn't enough to store all the CJK characters, and one character cell (about 8x16 pixels) wasn't enough to display them, so in CJK locales there were two-byte sequences that were interpreted as single characters in double-width cells of 16x16 pixels or so. I don't know much about Chinese and Korean, but in Japan the full-width ASCII characters were there because they were in the pre-existing JIS X 0201:1997 standard, and, I suppose, because they look better in combination with Japanese characters in some cases. The half-width katakana were useful because, for one thing, MS-DOS's 8.3 file name limit was 8.3 bytes, and four kana characters (and 1.5 in the extension) aren't really enough. It was just katakana and a few symbols because there wasn't room for anything more in a byte (along with ASCII and the double-byte lead values). Both widths are in Unicode so that a single terminal font can include them both, so that they can be distinguished in file names, etc. -- BenRG (talk) 02:13, 1 April 2012 (UTC)[reply]

Audio on computer

If I playback a music file using one piece of audio software, and try to simultaneously re-record it using another piece of audio software (or another instance of the same package), is the signal converted to analog then redigitised in the recording process? If so, what is the liklihood of loss of audio quality in the final recording?--[ — Preceding unsigned comment added by 92.28.76.99 (talk) 18:05, 31 March 2012 (UTC)[reply]

I'm pretty sure the signal doesn't go through analog. Your sound card converts digital to analog, and there is no piece of electronics looking at the sound card's audio-out cable that can sample and re-digitize the signal. You could use a cable to connect audio-out to audio-in, and record that, in which case the signal would go through analog, but you'd know if you were doing that.

If the source file and/or recording program use lossy compression (e.g. mp3), there may be some degradation. For uncompressed or losslessly compressed, and with matching sampling rates, I'd expect little or no change in quality. At least unless there is some DRM involved. 88.112.59.31 (talk) 09:29, 1 April 2012 (UTC)[reply]

Borked USB drive

I have a USB flash drive which I forgot to unmount before removing. Now, when I insert the drive, the little light comes on on the drive to indicate it's plugged in but nothing appears on the computer. The light would normally flash if anything is being read or written, but there's nothing.

Following the advice from http://www.dotkam.com/2009/01/06/find-usb-flash-drive-device-in-linux/, and checking tail -f /var/log/syslog, I get:

Mar 31 22:39:09 MyPC kernel: [  150.760222] usb 2-1: new high speed USB device number 3 using ehci_hcd
Mar 31 22:39:10 MyPC mtp-probe: checking bus 2, device 3: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1"
Mar 31 22:39:10 MyPC mtp-probe: bus: 2, device: 3 was not an MTP device
Mar 31 22:39:10 MyPC kernel: [  151.306220] usbcore: registered new interface driver uas
Mar 31 22:39:10 MyPC kernel: [  151.324645] Initializing USB Mass Storage driver...
Mar 31 22:39:10 MyPC kernel: [  151.325010] scsi5 : usb-storage 2-1:1.0
Mar 31 22:39:10 MyPC kernel: [  151.326312] usbcore: registered new interface driver usb-storage
Mar 31 22:39:10 MyPC kernel: [  151.326321] USB Mass Storage support registered.
Mar 31 22:39:11 MyPC kernel: [  152.327286] scsi: unknown device type 16
Mar 31 22:39:11 MyPC kernel: [  152.327303] scsi 5:0:0:0: Bridge controller 5        :                E    PQ: 1 ANSI: 1
Mar 31 22:39:11 MyPC kernel: [  152.327856] scsi: unknown device type 16
Mar 31 22:39:11 MyPC kernel: [  152.327870] scsi 5:0:0:1: Bridge controller 5        :                E    PQ: 1 ANSI: 1
Mar 31 22:39:11 MyPC kernel: [  152.328599] scsi: unknown device type 16
Mar 31 22:39:11 MyPC kernel: [  152.328610] scsi 5:0:0:2: Bridge controller 5        :                E    PQ: 1 ANSI: 1
Mar 31 22:39:11 MyPC kernel: [  152.376781] scsi 5:0:0:0: Attached scsi generic sg2 type 16
Mar 31 22:39:11 MyPC kernel: [  152.377196] scsi 5:0:0:1: Attached scsi generic sg3 type 16
Mar 31 22:39:11 MyPC kernel: [  152.377597] scsi 5:0:0:2: Attached scsi generic sg4 type 16

but I'm not sure what to do next - my output doesn't match that at the link above. Is there anything I can do to get this back? I don't need any of the data on it, so it's not a concern if it gets formatted and loses all my stuff, it'd just be good not to have to go and buy a new one. - Cucumber Mike (talk) 21:56, 31 March 2012 (UTC)[reply]

What filesystem has been on it, NTFS? If so connect it to a Windows computer and see if it automatically runs an fsck. If you don't have a Windows computer you should consider ceasing to use that FS for your USB sticks, and probably switch to FAT (if you want to still be able to use it with Windows computers) or ext4 (without a journal). If you really don't need the data on it, the quickest route to having it working again (if indeed it isn't physically broken), might be to just repartition/reformat it. http://webchat.freenode.net/?nick=usbtrouble&channels=#unix ¦ Reisio (talk) 02:07, 1 April 2012 (UTC)[reply]

Filesystem choice doesn't even become a thing until the device is at least identified as being storage. The usb-storage driver is loaded in the above log, but it didn't actually find a "disk" like it should have. Instead it found 3 "bridge" controllers (device type 16) and punted them to sg because the kernel doesn't know what the hell a scsi bridge is for. And neither do I. I can't find any evidence that device type 16 is supported by anything. To gather more information I recommend lsusb ; cat /proc/scsi/scsi but I'm not optimistic. It really looks like that poor USB stick has had its brains thoroughly scrambled.

Also, if the device was working with the same computer before, look in the older portion of the /var/log files to see what a successful mount looked like. If it never said "device type 16" until after the incident, that's bad news.

A remote possibility is that the device has gone back to a "factory newborn" state where it is trying to communicate with its Windows driver's setup program. In that case usb-modeswitch might be able to convince it to start behaving normally. But as far as I can tell that usually happens with communications devices that register themselves as storage devices, not with storage devices that register themselves as generic weirdness. 68.60.252.82 (talk) 06:45, 1 April 2012 (UTC)[reply]