[Ffmpeg-devel-irc] ffmpeg.log.20170922

[burek]

[00:00:14 CEST] <Johnjay> I've almost got my setup to convert youtube->mp3 finalized. I just need a way to click a link in the browser
[00:00:21 CEST] <Johnjay> and automatically get youtube-dl and ffmpeg to go to work on it
[00:00:28 CEST] <Johnjay> on a windows box if that wasn't clear
[00:00:55 CEST] <Johnjay> unless there's some other way i'll have to resort to autohotkey
[00:01:20 CEST] <rjp421> afaik raspivid isnt *necessary*, now that ffmpeg has h264_omx.. but last i checked i cant h/vflip without raspivid
[00:02:39 CEST] <furq> there might be a way to force the pi cam to give you rawvideo
[00:02:55 CEST] <furq> in which case you can just hflip/vflip as you normally would with ffmpeg and then encode it from there
[00:03:01 CEST] <furq> that might be slower though
[00:03:08 CEST] <Johnjay> what's the difference between raspivid and rawvideo?
[00:03:24 CEST] <furq> raspivid outputs h264 iirc
[00:03:36 CEST] <furq> but it uses the encoder chip on the pi, which ffmpeg can use
[00:04:15 CEST] <Johnjay> i see
[00:04:41 CEST] <furq> rjp421: try -f rawvideo or -c:v rawvideo before -i
[00:04:51 CEST] <furq> and -i /dev/video0 or whatever instead of piping
[00:05:04 CEST] <furq> it's probably -c:v rawvideo -f v4l2 -i /dev/video0
[00:05:39 CEST] <rjp421> furq, how does raspivid do the h/vflip before encoding? can ffmpeg copy its process?
[00:05:47 CEST] <furq> i have no idea
[00:06:09 CEST] <furq> if it's something built into vc then ffmpeg will be slower
[00:06:23 CEST] <furq> but i don't think it's a very slow operation really
[00:06:30 CEST] <furq> it's worth a try anyway
[00:10:33 CEST] <thebombzen> hflip and vflip are very fast
[00:11:28 CEST] <thebombzen> vflip especially because memcpy
[00:25:18 CEST] <kerio> furq: did you just say "might"
[00:25:21 CEST] <kerio> it's HELLA SLOW
[00:25:31 CEST] <kerio> copying raw crap from and to the videocore
[00:28:29 CEST] <SavinaRoja> is there a non web-based dash segment validator, the official one seems to be unresponsive and the dash muxer output i'm producing appears to be nonconformant in the segments
[00:31:32 CEST] <matteo> hi all
[00:31:34 CEST] <matteo> ffmpeg -y -video_size 256x144 -framerate 25 -f x11grab -i :0.0+0,0 -c:v ffvhuff  ppp.avi
[00:31:38 CEST] <matteo> what's wrong in this grab command?
[00:31:43 CEST] <matteo> it only grabs 34 frames
[00:40:56 CEST] <llogan> did you press "q"?
[00:41:28 CEST] <llogan> command looks ok
[00:41:37 CEST] <llogan> console output looks blank
[00:43:30 CEST] <llogan> guess he pressed "q"
[04:44:25 CEST] <chocolate-elvis> anyone having issues encoding files from FCP X? getting lookahead errors when encoding.
[04:44:56 CEST] <chocolate-elvis> from H264 mov files exported from FCP 10.3.4
[09:37:54 CEST] <lindylex> I am using this to place to videos side by side : ffmpeg -i c4.mov -i c5.mov -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w; [0:a][1:a]amix" -y t.mp4  I want to add a black border between the two videos. I tired adding the following pad=iw+1:ih:0:0 .  It add a border to the video on the right.  This make sense because the filter complex treats the video as one large video.
[10:09:33 CEST] <Gaulois94> Hello
[10:11:37 CEST] <Gaulois94> Hum, I may have a problem about sending an encoded frame... Here is the code, with the main loop : https://pastebin.com/aeF3Ea9b
[10:12:07 CEST] <Gaulois94> I don't know why, vlc can't read the full stream. Though, it detects images and can draw them each time I open the file
[10:22:19 CEST] <Gaulois94> Sorry, wrong file version : https://pastebin.com/k5ACACGV
[17:25:32 CEST] <Johnjay> I'm amazed I was able to tweak the windows cmd box
[17:25:43 CEST] <Johnjay> so I can just type "mp3 <filename>" and have ffmpeg convert it to mp3
[17:32:08 CEST] <Diag> yes
[17:32:10 CEST] <Diag> windows is good
[17:32:39 CEST] <iLoveWindows> very very good
[17:35:06 CEST] <Johnjay> lol
[17:35:13 CEST] <Johnjay> I detect some sarcasm here
[17:39:08 CEST] <Diag> nah windows is the shit
[17:39:22 CEST] <Diag> I do like da terminal on *nix
[17:39:23 CEST] <Diag> but
[18:17:11 CEST] <blap> good for whom?
[18:18:31 CEST] <Johnjay> is there an ffmpeg filter that rotates a file by time t?
[18:18:41 CEST] <Johnjay> i.e. takes the first t seconds and cuts it to the end?
[18:19:34 CEST] <squirrel> hi. i've got an old-ish tv that supports this https://fluf.cf/s/xi4gqj1502 , and the following avi is not playing on it https://fluf.cf/s/ze67sukjz4 , saying something about drm
[18:19:55 CEST] <squirrel> can i somehow verify that the file has some drm in it?
[18:20:29 CEST] <squirrel> it plays on my computer just fine
[18:34:27 CEST] <relaxed> squirrel: pastebin.com the output of ffmpeg -i file
[18:35:23 CEST] <squirrel> relaxed: https://fluf.cf/p/xqf11x69ah
[18:37:28 CEST] <relaxed> pal or ntsc?
[18:38:05 CEST] <CoreX> its pal file
[18:38:06 CEST] <CoreX> 25 fps, 25 tbr, 25 tbn, 30k tbc
[18:38:20 CEST] <relaxed> er, this is an hdtv ?
[18:39:07 CEST] <squirrel> well, it's the usual full hd resolution tv
[18:39:17 CEST] <squirrel> some obscure uk brand named jmb
[18:40:51 CEST] <squirrel> i did $ ffmpeg -i input.avi output.avi (just this, no other options), and now the tv plays the file. but the picture is very distorted
[18:41:31 CEST] <squirrel> well, not ditorted..
[18:42:13 CEST] <squirrel> that's how it looks now https://fluf.cf/s/cxn749axbv
[18:43:13 CEST] <relaxed> try, ffmpeg -i input.avi -c:v mpeg4 -q:v 2 -c:a libmp3lame -b:a 192k -ac 2 -vtag XVID output.avi
[18:44:06 CEST] <squirrel> will try, brb
[18:44:42 CEST] <Johnjay> -vol says that 256 is normal audio. i wonder if i understood mp3 if that would make more sense
[18:53:08 CEST] <squirrel> relaxed: works like a charm, thanks a bunch! e
[18:53:33 CEST] <squirrel> i'll investigate the parameters that you used
[18:55:35 CEST] <JonnyGreen> Hello guys, do you know if there is a command to list the timestamps of a video please ?
[18:55:49 CEST] <JonnyGreen> I want to be sure each frame has the right timestamp
[18:56:05 CEST] <Johnjay> squirrel: why did that command work?
[18:57:44 CEST] <squirrel> Johnjay: beats me. ffmpeg is magic in my books
[18:57:59 CEST] <Johnjay> ok. at least you're honest about it.
[19:05:51 CEST] <JonnyGreen> Hello, I have an mp4 video that I've encoded with iOS at 30 fps. I don't know why, but when I play it on the facebook player or other players, there is some lag. I was wondering if there was some problems with my encoding. How can I be sure there are no problems ?
[19:06:24 CEST] <JonnyGreen> Do you know if there is an ffmeg util to list problems ? Can I debug the timestamps ?
[19:07:49 CEST] <Mavrik> ffprobe -show_frames
[19:07:54 CEST] <Mavrik> will list all the frames with timestamps
[19:08:10 CEST] <Mavrik> Also remember that mobile devices (including iPhones) don't record with constant frame rate
[19:11:07 CEST] <JonnyGreen> ffprobe -i <input> -show_frames
[19:11:07 CEST] <JonnyGreen> ?
[19:11:51 CEST] <JonnyGreen> Oh yes, thanks it works !
[19:11:58 CEST] <JonnyGreen> I have these values for example :
[19:12:00 CEST] <JonnyGreen> 11.800000
[19:12:07 CEST] <JonnyGreen> 11.833333
[19:12:15 CEST] <JonnyGreen> 11.866667
[19:12:25 CEST] <JonnyGreen> 11.900000
[19:12:30 CEST] <JonnyGreen> Looks correct for 30 fps...
[19:19:50 CEST] <JonnyGreen> Thanks Mavrik anyway !
[20:12:09 CEST] <Sebas_> Hi :) I created a mpd file with multiple representations for video and audio.. but how can I control min_seg_duration for each video? Or can I compile them seperate then merge mpd files?
[20:12:23 CEST] <Sebas_> lower bitrate gives very small chunk files :)
[20:23:17 CEST] <Sebas_> Does ffmpeg have a merge options? or should I use DOM code to merge them into a single mpd file?
[20:58:54 CEST] <Sebas_> Was able to merge automaticly using my own code :) works.. audio segments are 10x longer then video now less http requests
[20:59:19 CEST] <Sebas_> also lower bitrate segments are longer now
[21:53:40 CEST] <martyrs> Hello, i have a video which encoded in 1920x1080, ffprobe output: https://pastebin.com/2xGXDrKF
[21:54:00 CEST] <martyrs> i am trying to generate 720p and 480p versions for this video
[21:54:56 CEST] <martyrs> but 480p versions gives me "[SAR 1280:1281 DAR 16:9]" in ffprobe, i just want to know if it's normal to get SAR 1280:1281 value
[21:55:16 CEST] <martyrs> while 720p version gives me [SAR 1:1 DAR 16:9] in ffprobe
[21:56:02 CEST] <martyrs> here are the commands i am running https://pastebin.com/sqb5mB6A
[22:11:02 CEST] <martyrs> i have multiple commands to convert video to 480p but i don't know which way is the best. "-vf scale=-2:480", "-vf scale=854x480,setsar=1:1" or "-s hd480"
[22:30:46 CEST] <furq> the first one
[22:31:05 CEST] <furq> except add -sws_flags lanczos
[22:35:39 CEST] <martyrs> @furq "-sws_flags lanczos", right?
[22:36:31 CEST] <martyrs> should i add it for 720p command too?
[22:36:43 CEST] <martyrs> "ffmpeg -i 819.mp4 -vf scale=-2:480 -sws_flags lanczos -c:v libx264 -c:a copy 819_480p.mp4"
[22:36:52 CEST] <thebombzen> I have an HEVC video file that decodes correctly with the ffhevc software decoder, but hevc_cuvid produces hideous artifacts
[22:37:05 CEST] <thebombzen> is this the fault of cuvid, or should I send a sample?
[22:40:49 CEST] <BtbN> Even if you send a sample, there's not much to be done
[22:41:02 CEST] <BtbN> Is it 10 or 12 bit stuff?
[23:03:34 CEST] <furq> martyrs: you should always add that when downscaling unless you have a messy source
[23:03:59 CEST] <furq> the default is bicubic which is a bit better for hiding artifacts
[23:04:34 CEST] <furq> you could also use -f zscale=-2:480:f=lanczos if your build has zscame
[23:05:04 CEST] <furq> l
[23:05:13 CEST] <martyrs> this is my final command for encoding both 720p and 480p
[23:05:26 CEST] <martyrs> "ffmpeg -i 819.mp4 -vf scale=-1:720 -sws_flags lanczos -c:v libx264 -c:a copy 819_720p.mp4 -vf scale=-2:480 -sws_flags lanczos -c:v libx264 -c:a copy 819_480p.mp4"
[23:05:43 CEST] <furq> you probably want some x264 options in there
[23:06:14 CEST] <BtbN> it's also more efficient to do that in seperate processes
[23:06:26 CEST] <furq> it is?
[23:06:28 CEST] <BtbN> as ffmpeg will not encode in parallel, but sequentially
[23:06:46 CEST] <BtbN> feed frame to encoder 1, wait until it's done, feed to encoder 2, wait until it's done, next frame
[23:07:22 CEST] <BtbN> unless you are somehow bottlenecked by the decoder
[23:07:31 CEST] <furq> nice
[23:08:07 CEST] <martyrs> furq: which options for x264?
[23:08:13 CEST] <furq> -crf -preset -tune
[23:08:19 CEST] <furq> are the usual ones you want to change
[23:08:24 CEST] <martyrs> BtbN: so i should run 720p and 480p seperately
[23:08:35 CEST] <furq> if this is for hls then maybe the defaults will be ok
[23:08:38 CEST] <furq> or dash or whatever
[23:08:47 CEST] <furq> but they're not really suitable for archival
[23:08:47 CEST] <martyrs> furq: default CRF is 23, right?
[23:08:48 CEST] <BtbN> the defaults are almost never ok
[23:08:50 CEST] <furq> yes
[23:09:21 CEST] <martyrs> and do you guys know how to set moov atom at the beginning of the video?
[23:09:27 CEST] <furq> -movflags faststart
[23:09:34 CEST] <BtbN> +
[23:09:39 CEST] <furq> do you still need that
[23:09:42 CEST] <alexpigment> nope
[23:09:45 CEST] <alexpigment> it's optional
[23:10:11 CEST] <martyrs> where i should add -movflags faststart option?
[23:10:35 CEST] <furq> before both outputs
[23:12:34 CEST] <alexpigment> also, re: doing those processes separately as BtbN suggested - separate will use up more CPU and often end up faster, but it's also pretty harsh on your resources. use them together like you have them if you plan on doing other things concurrently on the system
[23:12:38 CEST] <alexpigment> just my 2 cents, of course
[23:13:04 CEST] <BtbN> that's a weird suggestion
[23:13:15 CEST] <BtbN> use nice if you want to use the CPU for something else at the same time
[23:13:19 CEST] <alexpigment> there's also some scenario where it's slower, but it's been a few months since I did the benchmarks
[23:13:23 CEST] <furq> if that command is consistently using 100% cpu then it's probably fine
[23:13:40 CEST] <martyrs> well, my server has some load, it's a production server i can say
[23:13:41 CEST] <furq> i can't imagine it's massively quicker to run them separately
[23:13:52 CEST] <martyrs> so actually i have 700 videos to be processed
[23:13:56 CEST] <alexpigment> I'm just relaying my experience with it. I'm not sure if it was the CPU alone, but I would get crazy system lag when using separate processes
[23:14:06 CEST] <furq> were you swapping or something
[23:14:08 CEST] <martyrs> i'd like to do it slowly and by limited cpu power
[23:14:18 CEST] <BtbN> Use a high niceness then
[23:14:21 CEST] <alexpigment> furq: it was marginal in my experience
[23:14:39 CEST] <BtbN> Or do them seperately, but not in parallel, but one after another
[23:14:41 CEST] <alexpigment> BtbN: I'll defer to your judgement on this
[23:15:10 CEST] <alexpigment> I think parallel was faster than sequential - just not faster than separate processes concurrently
[23:15:25 CEST] <BtbN> yes, doing it in parallel will almost always be faster
[23:15:35 CEST] <BtbN> but if it's about saving system resources, it's better
[23:15:39 CEST] <martyrs> and one more question
[23:15:51 CEST] <martyrs> should i encode 480p from 720p file?
[23:15:55 CEST] <martyrs> or 1080p file?
[23:16:09 CEST] <BtbN> Don't re-encode more often than neccesary
[23:16:22 CEST] <BtbN> Quality will never get better
[23:16:31 CEST] <alexpigment> yeah, 1080p to 480p
[23:16:41 CEST] <martyrs> okay so i should encode it from 1080p
[23:16:44 CEST] <alexpigment> 1080p to 720p is already mathematically innaccurate
[23:16:49 CEST] <martyrs> thats what i tought but just wanted to make sure
[23:16:57 CEST] <alexpigment> *inaccurate, rather
[23:18:14 CEST] <alexpigment> martyrs: for reference, furq mentioned using lanczos earlier because you're doing non-integer scaling. 1080/720=1.5, 1080/480=2.25
[23:18:43 CEST] <alexpigment> as you can imagine, the scaler has to make some less-than-optimal decisions about what to do with your pixels
[23:19:06 CEST] <alexpigment> when you go from 1080p to 720p to 480p, you're amplifying those bad decisions
[23:19:17 CEST] <alexpigment> in addition to re-encoding and losing quality, as BtbN pointed out
[23:20:11 CEST] <martyrs> alexpigment: got it
[23:20:40 CEST] <furq> reencoding is the bigger problem there by far
[23:20:47 CEST] <furq> especially at crf 23, preset medium
[23:21:01 CEST] <furq> but yeah you should always use the original copy regardless
[23:21:02 CEST] <alexpigment> true, just pointing out the scaling issues in the event that it comes up again in a lossless encode scenario
[23:21:22 CEST] <furq> you should use the highest quality copy you have in general
[23:21:32 CEST] <martyrs> btw, when encoding to 480p, i get "Stream #0:0(eng): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 854x480 [SAR 1280:1281 DAR 16:9], q=-1--1, 60 fps, 15360 tbn, 60 tbc (default)"
[23:21:36 CEST] <furq> even if that means downloading it in 4k from usenet
[23:21:45 CEST] <furq> i mean uh
[23:21:47 CEST] <martyrs> 854x480 [SAR 1280:1281 DAR 16:9], is this normal to have SAR 1280:1281?
[23:21:47 CEST] <furq> acquiring it legally
[23:21:49 CEST] <alexpigment> furq: haha
[23:22:23 CEST] <alexpigment> martyrs: it's because 854x480 isn't a true 16x9 resolution
[23:22:27 CEST] <alexpigment> it's slightly off
[23:22:30 CEST] <furq> ^
[23:22:41 CEST] <alexpigment> mathematically, it should be 853.333333
[23:22:52 CEST] <alexpigment> the SAR is adjusted to be slightly less than 1:1 to account for this
[23:23:09 CEST] <martyrs> alexpigment: oh, understood
[23:23:29 CEST] <alexpigment> 16x9 480p has caused me more headaches over the years than any other format
[23:23:39 CEST] <furq> how much of that has to do with dvd
[23:23:42 CEST] <alexpigment> there's always something that doesn't want to play it right
[23:23:49 CEST] <alexpigment> furq: for me, none actually
[23:24:08 CEST] <alexpigment> it's how web players and browsers and standalone video players deal with it
[23:24:39 CEST] <martyrs> as you can see, video recorded in 60fps, should i specify any specific profile while encoding?
[23:25:02 CEST] <martyrs> visually, CRF 23 looked good to me, so i just decided to leave everything default
[23:25:34 CEST] <alexpigment> martyrs: I personally really dig 480p60 as a format, but if device compatibility is a concern, there is an argument to be made for doing 480p30 instead
[23:25:51 CEST] <alexpigment> that being said, I personally would just leave it as is in terms of the framerate
[23:26:02 CEST] <martyrs> on my original videos (1080p), i use 15000kb/s bitrate, which is really high for average connections
[23:26:08 CEST] <furq> martyrs: there's never any need to set the profile manually nowadays
[23:26:20 CEST] <furq> unless you're targeting super old devices or BD compatibility
[23:26:30 CEST] <furq> you might need to set the level for 720p60, idk
[23:26:47 CEST] <alexpigment> there was an Apple TV that required 720p to be Main profile, but fortunately that device is effectively dead ;)
[23:27:08 CEST] <martyrs> when i render footage using adobe premiere, 60fps only renders in High 5.1 profile or something
[23:27:19 CEST] <alexpigment> martyrs: that means the bitrate is high
[23:27:27 CEST] <alexpigment> 1080p60 is generally level 4.2
[23:27:34 CEST] <alexpigment> but if the bitrate spikes, you end up at 5.1
[23:27:43 CEST] <furq> you might want to clamp the 720p60 encode at level 4.1
[23:27:51 CEST] <furq> but it won't make a difference with preset medium
[23:28:13 CEST] <alexpigment> i have a feeling 720p60 would never hit 4.2 at crf 23 ;)
[23:28:27 CEST] <furq> it probably would with -preset veryslow because of the refs
[23:28:32 CEST] <furq> i can't remember the specifics though
[23:28:45 CEST] <martyrs> may you guys explain little bit more about difference between levels? i always ended up with 5.1 while encoding 15mbit bitrate and 60fps
[23:29:08 CEST] <furq> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
[23:29:26 CEST] <alexpigment> martyrs: there may just be a setting you need to turn down to 4.2
[23:29:26 CEST] <furq> that doesn't mention it but the number of reference frames also makes a difference
[23:29:38 CEST] <furq> you generally don't want to go above 4.1 if you want widespread hwdec support
[23:29:50 CEST] <alexpigment> yeah, but if you want to do 1080p60, 4.2 is where you'd cap it
[23:30:07 CEST] <alexpigment> but yes, 1080p60 is a bit of a decoder crapshoot
[23:30:11 CEST] <furq> yeah
[23:30:33 CEST] <furq> it's generally not something you need to worry about unless you're encoding 1080p
[23:30:36 CEST] <furq> or above
[23:31:10 CEST] <furq> setting -profile and -level in ffmpeg with x264 will disable certain settings that would exceed that level
[23:31:29 CEST] <furq> but you can't set -level 1 with 1080p60, say
[23:31:40 CEST] <furq> unless you want a broken file
[23:32:01 CEST] <martyrs> can i set 4.1 for 720p version?
[23:32:23 CEST] <furq> it's better not to set it unless you know it'll exceed it
[23:32:48 CEST] <furq> if you set 4.1 on a file that only needs 3.0 then it'll still flag it as 4.1
[23:32:55 CEST] <furq> it'll show you the output level when you start running an encode
[23:32:57 CEST] <alexpigment> 720p60 will usually stay at 3.2 automatically
[23:33:01 CEST] <furq> yeah
[23:33:09 CEST] <martyrs> is there any way to check current level with ffprobe?
[23:33:16 CEST] <furq> -show_streams
[23:34:36 CEST] <martyrs> level 5.1 with original file, level 3.2 with 720p and level 3.1 with 480p
[23:35:07 CEST] <martyrs> looks good, right?
[23:35:32 CEST] <furq> yeah that's about what i'd expect
[23:35:51 CEST] <martyrs> okay and how about limiting audio bitrate on 480p version?
[23:35:56 CEST] <martyrs> original file audio is 320kb
[23:36:04 CEST] <furq> ac3?
[23:36:10 CEST] <martyrs> aac
[23:36:15 CEST] <furq> is that 5.1
[23:36:34 CEST] <furq> that's a really weird choice for stereo
[23:36:43 CEST] <martyrs> original file:     Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 317 kb/s (default)
[23:36:47 CEST] <furq> lol
[23:37:02 CEST] <furq> yeah that's really excessive
[23:37:25 CEST] <furq> i normally use fdk_aac -vbr 5, but the builtin aac encoder should do just fine at 128k
[23:38:22 CEST] <martyrs> do you think aac is a good choice for playback compability?
[23:39:21 CEST] <furq> it's the only choice
[23:39:46 CEST] <martyrs> -c:a libfdk_aac -b:a 128k
[23:40:17 CEST] <martyrs> going to try it now :)
[23:40:27 CEST] <furq> if you didn't build ffmpeg yourself then you won't have fdk-aac
[23:40:39 CEST] <furq> but -c:a aac -b:a 128k will work and do a fine job
[23:40:47 CEST] <martyrs> oh it's external library, right
[23:40:54 CEST] <martyrs> k going to use builtin then
[23:42:47 CEST] <furq> anything starting with lib is external
[23:43:05 CEST] <furq> but builds with fdk are non-redistributable because it's not gpl compatible
[23:43:20 CEST] <alexpigment> furq: aac caps out at 320kbps, generally speaking. perhaps an odd choice, but it makes sense in that respect
[23:43:54 CEST] <alexpigment> but yeah, 128kbps is more than acceptable for aac
[23:44:13 CEST] <furq> yeah if it's for streaming then i guess it sort of makes sense
[23:44:22 CEST] <furq> for archival that would be dreadful
[23:44:39 CEST] <furq> also "sort of makes sense" in the sense that it still sucks but i can at least understand how the decision was arrived at
[23:44:56 CEST] <martyrs> i set 64kbps for 480p version and 128kbps for 720p version
[23:45:11 CEST] <alexpigment> 64kbps is low, but should still be ok
[23:45:14 CEST] <furq> you might as well use 128k for both really
[23:45:15 CEST] <alexpigment> if you find it's too low, try 96
[23:45:17 CEST] <alexpigment> k
[23:45:54 CEST] <alexpigment> i've never personally used 64kbps for stereo audio, but again, it's not terrible with aac
[23:45:54 CEST] <martyrs> just experimenting but yeah 128k should be fine for both i think
[23:46:26 CEST] <alexpigment> anyone remember when Windows Media Player ripped at 64kbps MP3 by default? ;)
[23:46:45 CEST] <alexpigment> rather, 64kbps WMA
[23:46:48 CEST] <furq> nice
[23:46:49 CEST] <alexpigment> anyway, THAT was unlistenable
[23:46:56 CEST] <furq> tbf the wmp builtin mp3 encoder was just as bad
[23:47:12 CEST] <alexpigment> well, it didn't default to that level
[23:47:14 CEST] <furq> i remember seeing friends ripping cds with wmp in like 2006 and getting really upset with them
[23:47:22 CEST] <furq> NO YOU MUST USE "EAC"
[23:47:25 CEST] <alexpigment> the whole thing was a tie-in with Zune so that they could advertise more songs compared to the iPod
[23:47:33 CEST] <furq> it was like i'd told them to go to jupiter
[23:48:01 CEST] <alexpigment> well, it really only mattered when you were using an on-the-cusp bitrate
[23:48:12 CEST] <furq> with that said it was only a couple of years before that that i copied a cd by ripping it to 128k mp3 and then burning those to the cd
[23:48:16 CEST] <alexpigment> if you ripped at 192kbps or higher, the difference was not significant
[23:48:28 CEST] <furq> while i still had the original cd in my computer
[23:48:33 CEST] <alexpigment> furq: great archival work ;)
[23:48:43 CEST] <alexpigment> "this'll do."
[23:48:50 CEST] <furq> i genuinely didn't understand why it made a difference
[23:49:00 CEST] <furq> but then i'd have been 17 at the time so it was almost certainly a shit cd anyway
[23:49:01 CEST] <alexpigment> i hope it was something awful like "let the bodies hit the floor" by drowning pool
[23:49:07 CEST] <furq> most likely
[23:49:28 CEST] <furq> i think it might have actually been a DISTURBED album i was copying for a friend
[23:49:33 CEST] <alexpigment> i'd like to tell anyone who saw my CDs in the late 90s, *there wasn't really a whole lot of choice*
[23:49:44 CEST] <alexpigment> furq: i had that album too, I must admit
[23:49:49 CEST] <furq> that's right folks...i was down with the dang sickness
[23:49:50 CEST] <sabusanta> lol
[23:50:21 CEST] <alexpigment> I bought it after hearing "stupify". i didn't realize the rest was a bunch of musical coughing and gagging noises
[23:50:41 CEST] <sabusanta> That "Let The Body Hit The Floors" song is overplayed in the military in every presentation that could ever be
[23:50:50 CEST] <alexpigment> man, that's so wrong
[23:51:20 CEST] <alexpigment> also, it's like a genuinely bad song. i give no passes on ever liking that song ;
[23:52:10 CEST] <martyrs> and anyone remember Audiograbber?
[23:52:13 CEST] <sabusanta> I thought it was decent. Tho, I've always was a fan of "that genre" when I was young.
[23:52:24 CEST] <alexpigment> martyrs: the hand animation is etched into my brain
[23:52:36 CEST] <martyrs> alexpigment: hahah, same here
[23:52:44 CEST] <furq> http://www.audiograbber.org/
[23:52:49 CEST] <furq> i can't believe that site is still up
[23:52:58 CEST] <alexpigment> sabustanta: you might get a kick out of the website theprp.com . they still cover nu metal for some reason, but the comments section for every story is hilarious
[23:53:19 CEST] <sabusanta> alexpigment: Thank I will try to later
[23:53:24 CEST] <alexpigment> i can't remember what the deal was with audiograbber
[23:53:33 CEST] <sabusanta> Now have 75 tabs open.
[23:53:42 CEST] <alexpigment> the Xing company made a product that was exactly like it with a slightly different name
[23:53:55 CEST] <alexpigment> so i don't know if they sold the tech or what
[23:54:14 CEST] <alexpigment> Xing Audio Catalyst - that's it
[23:54:52 CEST] <martyrs> aahh, audiocatalyst
[23:54:57 CEST] <martyrs> that was so popular
[23:55:19 CEST] <furq> lol i think i used that
[23:55:30 CEST] <alexpigment> yeah, the wikipedia doesn't say it specifically, but audiograbber may have just been a ripoff of audio audiocatalyst that used LAME instead of Xing's encoder
[23:55:40 CEST] <alexpigment> I definitely used audio catalyst
[23:56:04 CEST] <alexpigment> as well as Winamp, before I knew any better
[23:56:14 CEST] <alexpigment> (their ripper, I mean)
[23:56:24 CEST] <alexpigment> it was limited to 2x until you paid for Winamp Pro :(
[23:57:16 CEST] <alexpigment> also Musicmatch Jukebox - that one was pretty good actually, although it was bloated as hell
[23:59:06 CEST] <martyrs> Dance eJay, best software back in '99
[23:59:55 CEST] <alexpigment> that one flew past my radar I guess
[00:00:00 CEST] --- Sat Sep 23 2017