Post by PaulI checked my copy of VLC, and in Convert/Save under the Network entry,
it has an entry from the last time someone asked a question about VLC
:-)
https://playerservices.streamtheworld.com/api/livestream-redirect/KUSCAAC96.m3u8
According to the Title at the top of the VLC window, I am
Carl Stamitz - Clarinet Concerto #11 in Eb # E flat major ???
If I use bash shell, for the "file" command, my output (because I
elected to "convert" in VLC and I selected the "MP3" option which
$ file sample-VLC-convert.mp3
sample-VLC-convert.mp3: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo
So VLC is preparing a 128Kbit/sec output as MP3 from the raw incoming
stream. Whatever AAC96 format incoming at the moment is.
Since this is streaming conversion, no sound card is required, but...
it still takes six hours, if the selection actually lasts six hours
before the connection stops. Streaming servers don't generally run
for infinite time, but break the connection once in a while.
Streaming can be much faster than playback speed. I use a local proxy
that captures video/audio stream, and it captures at whatever is the
maximum speed the media server will stream the content. A 4-hour video
may take 1 to 20 minutes to capture. Depends on delivery speed from the
media server. I've rarely hit a server that throttles its speed per
connect down to playback speed since that would also prevent the client
from buffering the content to eliminate artifacts, like stutter or
cutouts.
VLC is a player, not a stream capture tool, so it might be capturing
(converting) only at its own playback speed. If that happens, I would
use something else to capture the stream to significantly reduce capture
time, and then convert it locally instead of at attempting the
conversion at the end of transport. I haven't had VLC do a convert for
a long time, but I thought it first "played" the stream to capture it,
and then did a local conversion if the user elected a different file
format. If true, a local conversion would take as long as to playback
the stream to capture it, and then due a local (and probably faster)
conversion. To me, using a player to do the capture is the slow way.
I don't see the sound card is important or even employed since capturing
a stream does not necessarily mean you are yet playing the stream. When
I capture a stream, nothing is played of it until I choose after the
capture completes to then play the generated local file. I can see my
capture software first does the capture, and then does a conversion, if
elected, on a local file. I rarely do conversions, so I don't know how
long it takes after the capture for how long to generate the converted
file. When capturing video streams (with audio), typically those
generate local .mp4 files. I believe capturing audio files is usually
already in .mp3 format. However, what you capture depends on what the
server delivers, and that could be multiple formats. The capture
software I use lets me pic a preferred format for the local file. No
conversion if the server delivers in the preferred format, but a
conversion if the server delivers different than my preference.
I [tried to] capture the .mp3 file you mentioned at the URL of:
http://playerservices.streamtheworld.com/api/livestream-redirect/KUSCMP128.mp3
That site *severely* throttles their connections. I gave up after 30
minutes whereupon the media server had, so far, only delivered 35 MB of
an audio-only stream (don't know what would've been the full size for
the fully captured audio stream) - a measly 1.17 MB/min delivery rate
... EXTREMELY SLOW. I had far better things to do than waste time
waiting on an extremely slow media server, or one that throttles down to
playback speed. A 601 MB 1-hour 47-minute video+audio stream from
https://lookmovie2.to/ ("IF" movie) took under 1 minute to capture (I
paused the movie playback to eliminate that bandwidth to just focus on
the bandwidth for the capture), so 601 MB/minute which is more than 17
times faster than the media server at streamtheworld.com. How fast you
can capture depends a lot on how fast the media server will deliver.
I didn't bother trying to use VLC to change the encapsulation format
(which probably wouldn't take much time, like .mp4 to .mkv) nor convert
to a different codec (i.e., recoding) to see how long to convert the
local file from the .mp4 movie capture to some other format. That would
be a conversion on a local file, so how long depends on how fast is the
convert tool. Again, I don't see a sound card is employed in capture
nor in conversion (to change encapsulation or codec recoding).
jMR uses yt-dlp for capture and ffmpeg to convert, but jMR handles all
the conflicts in arguments, and provides a GUI to more easily choose
settings. I looked into (and downloaded) the yt-dlp and ffmpeg tools
which are free as command-line tools ((and yt-dlp-gui for a GUI
frontend), but sometimes I hit a site where capture doesn't work, so I
report the issue to jaksta, and they come up with a workaround in a day,
or a fix in 1 to 3 days. I don't have to figure out how to experiment
to rework the command line to get yt-dlp and ffmpeg to work for a
particular site. They already have a bunch of rules for different sites
to get these tools working there, and a fix that is just another rule
takes little time to produce and distribute via auto-update. Once they
have the session log, they usually have a fix in a day. Much easier to
buy a payware product where support is excellent, and fixes show up in a
few hours to a couple days than me doing all that experimentation and
wasting time on the effort.
I really don't want to self-educate over a vast number of trials to
become an expert in getting yt-dlp and ffmpeg working everywhere I snag
streams. Been a long time since I did my own oil filter and changes,
too, on my cars since the cost savings nowadays is small: $22 for the
synthetic blend oil, $8 for the filter, and $10 per trip to the
hazardous disposal site versus the shop's $40 special, so I don't come
out ahead, anyway, plus I would've had to put the car up on ramps and
jacks, sneak underneath on a crawler, collect the oil, store the old
oil, clean up any mess if just having the clean the oil tray, and hold
the old oil until a trip to the hazardous waste site. Just not worth
the hassle to me to do the work. Same for figuring out why yt-dlp and
ffmpeg didn't work, but some folks discount their time and effort as
being free, and want to experience the tribulations to self-educate
while troubleshooting. Free is often not so free.
None of the capturing or conversion involves a sound card. However,
"personal, feet-on-the-ground, real-word, experience" might mean the OP
is plugging a microphone into the input jack on a sound card. However,
the OP also mentioned a streaming site, and capturing a stream, and
converting the locally generated file, doesn't involve a sound card.