VLC writing junk data when converting streams?
Posted: 15 Nov 2013 18:14
I occasionally use VLC to record WMA streams from a radio station to disk. To that effect I use VLC's Convert feature.
I understand that it would be possible to dump the raw stream by ticking the respective checkbox in VLC's convert dialog. This will result in a WMA file of around 22 MB per hour, which matches the 48 kbps stream I record from. However, using the Dump raw input feature, VLC's seek bar and time display is non-functional, so I can't see how much of the program has already been dumped. I don't know whether this is a bug or whether there is some reason behind it. Both current position and total duration always show "00:00", and the only indication I have that the stream is still recording is that the Pause button has not yet changed back to the Play button.
To get around this I created a custom conversion profile with the following settings: ASF/WMV container, video and subtitles deactivated, audio conversion active but with the Keep original audio track checkbox on. When I dump the stream like this, the WMA file is written correctly, and I do get the seek bar and time indicator in VLC's GUI. However, the resulting files will be around 38 MB per hour, and I don't know where or what these additional 16 MBs are. Examining files recorded with both methods in MediaInfo, I see that the raw input dump at 22 MB retains the original publisher's container metadata and has one WMA stream at 48 kbps making up 99% of the file size. Files recorded using my own profile obviously have VLC's container metadata, but also only one 48 kbps WMA stream which, however, makes up only 54% of the file size (more or less the 22 MB it should be). So, why is the file bloated to almost double its size if 46% of it doesn't even belong to any stream?
I am currently using VLC 2.2.0 win64 nightly from Nov 15th, but I have had this issue ever since I started dumping streams back with 2.0.8. Also, if instead of Convert I use the Stream feature with a file target and no conversion (:sout=#file{dst=[...]\Test.asf,no-overwrite} :sout-keep), the result is exactly the same as when using my profile.
Here are the MediaInfo outputs for two dumps done using Convert: using raw input dump on the left, and using a profile with no audio conversion on the right:
If it would be of any help, I could upload recordings of each kind for analysis.
On a related note, I have witnessed a similar thing when examining radio recordings made from my Samsung DVB-C TV. The MPEG-TS file that resulted from a 3-hour recording was around 1.53 GB in size, but it contained only one 160 kbps stereo MP2 stream, making up around 14% of the entire filesize. There was no video stream at all, the remaining 86%, or around 1.4 GB, did seem to be just junk data.
I understand that it would be possible to dump the raw stream by ticking the respective checkbox in VLC's convert dialog. This will result in a WMA file of around 22 MB per hour, which matches the 48 kbps stream I record from. However, using the Dump raw input feature, VLC's seek bar and time display is non-functional, so I can't see how much of the program has already been dumped. I don't know whether this is a bug or whether there is some reason behind it. Both current position and total duration always show "00:00", and the only indication I have that the stream is still recording is that the Pause button has not yet changed back to the Play button.
To get around this I created a custom conversion profile with the following settings: ASF/WMV container, video and subtitles deactivated, audio conversion active but with the Keep original audio track checkbox on. When I dump the stream like this, the WMA file is written correctly, and I do get the seek bar and time indicator in VLC's GUI. However, the resulting files will be around 38 MB per hour, and I don't know where or what these additional 16 MBs are. Examining files recorded with both methods in MediaInfo, I see that the raw input dump at 22 MB retains the original publisher's container metadata and has one WMA stream at 48 kbps making up 99% of the file size. Files recorded using my own profile obviously have VLC's container metadata, but also only one 48 kbps WMA stream which, however, makes up only 54% of the file size (more or less the 22 MB it should be). So, why is the file bloated to almost double its size if 46% of it doesn't even belong to any stream?
I am currently using VLC 2.2.0 win64 nightly from Nov 15th, but I have had this issue ever since I started dumping streams back with 2.0.8. Also, if instead of Convert I use the Stream feature with a file target and no conversion (:sout=#file{dst=[...]\Test.asf,no-overwrite} :sout-keep), the result is exactly the same as when using my profile.
Here are the MediaInfo outputs for two dumps done using Convert: using raw input dump on the left, and using a profile with no audio conversion on the right:
If it would be of any help, I could upload recordings of each kind for analysis.
On a related note, I have witnessed a similar thing when examining radio recordings made from my Samsung DVB-C TV. The MPEG-TS file that resulted from a 3-hour recording was around 1.53 GB in size, but it contained only one 160 kbps stereo MP2 stream, making up around 14% of the entire filesize. There was no video stream at all, the remaining 86%, or around 1.4 GB, did seem to be just junk data.