My Humax Forum » Freeview HD » FVP 4000T, 5000T

Radio recordings - dud mp3s

(15 posts)
  1. User has not uploaded an avatar

    TheMikeN

    junior member
    Joined: Apr '17
    Posts: 8

    offline

    I mastered the skill of transferring TV recordings from the FVP4000T and started doing the same with radio recordings. {I previously transferred both for many years from an old Humax 9300}.

    The mp3s I now end up with are roughly four times as large in memory usage as the equivalents used to be from the 9300
    AND, rather more importantly, they DON'T work. Totally silent, delay in starting playing followed by the playing progress bar whizzing across from left to right in three or four seconds - still silent. And these are files that take up nearly 500MB per hour!

    Is there a separate trick for audio files that I've missed. Simple dragging and dropping just isn't working. {They do play back on the FVP4000T itself so the recording has taken place successfully}.

    Any advice would be appreciated. Thanks!

    | Thu 1 Jun 2017 13:44:40 #1 |
  2. gomezz

    gomezz

    special member
    Joined: Mar '11
    Posts: 944

    online

    I use the free tsMuxer utility to extract the audio from radio recordings (RadMac on BBC 6 Music) copied from my Foxsat HDR to my laptop which I then copy to my PMP. These work out at 212MB for a 3:06 hour recording.

    | Thu 1 Jun 2017 13:51:11 #2 |
  3. User has not uploaded an avatar

    Luke

    special member
    Joined: Apr '11
    Posts: 1,499

    offline

    TheMikeN - 15 minutes ago  » 
    I mastered the skill of transferring TV recordings from the FVP4000T and started doing the same with radio recordings. {I previously transferred both for many years from an old Humax 9300}.

    Presumably the TV recordings are playable.Both standard definition TV and radio are encrypted when recorded and so you will need to use a method that decrypts them when you download.
    Are you sure that the radio recordings are decrypted?

    TheMikeN - 15 minutes ago  » 
    The mp3s I now end up with are roughly four times as large in memory usage as the equivalents used to be from the 9300

    They both use basically the same format and that format is not mp3. Some mp3 players will still be able to play them though.
    The reason that the FVP-4000T files are larger is that most of the mux's epg data is also dumped into the recording, while the PVR-93000T still includes a bit too much of the epg data it does not include all of it.

    To throw out the junk I make a selective copy using FFMPEG.
    ffmeg.exe -i "<input_URL>" -vn -acodec copy "<output_URL>"

    with the output file having a file extension of 'mpg'.

    Normally I do this through winff as winff handles batching many recordings into one long list to shrink, and it is also menu driven so that I don't have to remember any of the nitty gritty of the ffmpeg commands if I wanted to add top and tailing or some other common options.
    Both ffmeg and winff can also covert to mp3 at the same time if you want a true mp3.

    | Thu 1 Jun 2017 14:41:10 #3 |
  4. User has not uploaded an avatar

    BB

    senior member
    Joined: Oct '15
    Posts: 87

    offline

  5. User has not uploaded an avatar

    TheMikeN

    junior member
    Joined: Apr '17
    Posts: 8

    offline

    Thanks everyone for joining in and advising.

    The bit about file extensions almost matches with what I have discovered.
    [Actually, it wasn't me that thought of 'my' solution but my son who I was just taking out for driving practice before his test]. I mentioned the file sizes to him and he said 'Hang on, that's a bit large; have you tried changing the file extensions?}

    That got me thinking that the file sizes were roughly what a lossless (WAV or FLAC) file would be - roughly 500MB for an hour.

    So I came home, changed the extensions to WAV and - yippee! - everything worked. These aren't - and never were - mp3s. The current Humax software mislabels lossless files as lossy mp3s.

    So my solution has the same principles as those kindly suggested above but suggests a mislabelling bug in the current software.

    Thanks again for contributions above.

    | Thu 1 Jun 2017 16:39:19 #5 |
  6. grahamlthompson

    grahamlthompson

    special member
    Joined: Feb '11
    Posts: 14,442

    offline

    One thing is certain, they will not be .WAV files. To transmit lossless audio would massively increase the bandwidth required.

    The transmitted audio for radio and SD TV is heavily compressed MP2 (mpeg 1 layer 2) which has to be the format recorded (pvrs have no recoding capability, the broadcast stream is copied directly to a hard disk), heaven knows why the box says it is MP3. As Luke says the filesize is so large because of the large amount of unwanted data.

    MediaInfo will confirm the actual audio details (as posted in the older linked thread).

    https://mediaarea.net/en/MediaInfo

    | Thu 1 Jun 2017 16:53:55 #6 |
  7. User has not uploaded an avatar

    TheMikeN

    junior member
    Joined: Apr '17
    Posts: 8

    offline

    I don't think that's what I meant!
    Fear not, I'm not suggesting the transmission is at CD-quality/lossless/WAV/FLAC. It's the format the recording is being stored in that I was referring to. Any lossy, primitive recording can be saved as a WAV and, when it is, the filesize becomes comparatively huge.
    They may not actually be true WAV files but they play perfectly in that format... so at least the immediate problem is solved.
    Whatever, the labelling of each file in the directory after transfer by Humax's software as mp3s must be a mistake.

    | Thu 1 Jun 2017 17:20:50 #7 |
  8. User has not uploaded an avatar

    Luke

    special member
    Joined: Apr '11
    Posts: 1,499

    offline

    TheMikeN - 4 minutes ago  » 
    the labelling of each file in the directory after transfer by Humax's software as mp3s must be a mistake.

    It is. They are MP2s but with the full now/next epg data for the multiplex that they were broadcast on. It looks as though more players can play them if they have an extension of mpg.
    I suspect what is happening is that your player relaises that they are not WAV and so adjusts, but for some reason it does not come to the same conclusion if they have the extension of MP3.

    The reason that they are so large is because they also include the full now/next epg for the multiplex and that epg is broadcast repeatedly throughout the programme. The increase in size has nothing to do with the actual audio parts of the recording itself as that is exactly the same as the audio part of the recording of the PVR-9300T.

    | Thu 1 Jun 2017 17:38:29 #8 |
  9. grahamlthompson

    grahamlthompson

    special member
    Joined: Feb '11
    Posts: 14,442

    offline

    TheMikeN - 25 minutes ago  » 
    I don't think that's what I meant!
    Fear not, I'm not suggesting the transmission is at CD-quality/lossless/WAV/FLAC. It's the format the recording is being stored in that I was referring to. Any lossy, primitive recording can be saved as a WAV and, when it is, the filesize becomes comparatively huge.
    They may not actually be true WAV files but they play perfectly in that format... so at least the immediate problem is solved.
    Whatever, the labelling of each file in the directory after transfer by Humax's software as mp3s must be a mistake.

    PVR's have no built in way of recoding any of the content they receive (Unlike DVD Recorders). It's impossible for them to change the compression codec used for video and audio. Increasing the size (or reducing) the size of the audio content requires recoding either changing the codec and/or the bitrate used. The digital tuners simply extract the required digital content (Video, Audio, Subtitles and Audio Description data) and record it to a mass storage device (usually a hard disk). They can change the way the data is stored/packaged/multiplexed into the recorded stream (ie change the container used). Humax recorders generally store all recordings in a transport stream container (.ts).

    That's why a pvr's recordings are 100% identical to the original broadcast. DVDr's which do have real time mpeg encoding can change the recorded quality (and hence the filesize) on the fly and as a result are able to record from an analogue external input.

    It would however be fairly trivial to change the transport stream container to programme stream (.mpg) as no actual digital recoding is required.

    On other Humax recorders that allow direct export of files without any sort of change (eg the HDR-FOX-T2) when you export any recording you get a transport stream file with varying contents depending on the source (eg Freeview HD uses AAC rather than MP2 for audio compression codec).

    The HDR-FOX-T2 has a excellent custom firmware add on that amongst other capability is capable of removing the extraneous data from recordings, considerably reducing the filesize in the process.

    Unfortunately the 1800/2000T and 4000T model is much more locked down than the FOX T2 so especially in the case of the 4000T you can only get what the Humax software allows you to export.

    If you look at the file (with any name) using MediaInfo and locate the average bitrate used for the audio track and it's duration it's a simple calculation to work out the filesize of the actual audio data when all the unwanted data is deleted.

    | Thu 1 Jun 2017 17:59:14 #9 |
  10. User has not uploaded an avatar

    TheMikeN

    junior member
    Joined: Apr '17
    Posts: 8

    offline

    I see that you know a lot more about the machine itself than I do. Thanks for the explanation.

    To test it, I tried changing the extension to .ts from .wav

    The files do still play properly. I'd guess they would play smoothly with many different file extensions. Seems a bit clumsy that the one they are automatically given during the transfer process (mp3) is possibly the least likely to work because of the need for LAME encoding/decoding.

    So there's one request for a very minor software update: Please get the FVP4000T to use ANY correct default file extension following audio transfers.

    My other request to Humax is...
    Is there any chance of having HDD settings that allow transfer of TV files a bit faster than 'real time'? Hoping to carry and watch something I recorded the night before involves what I consider to be completely unnecessary usse of USB drives so far. Transfers straight from the HDD of a 9300T were often, quite literally twenty times faster. Wireless is nice but the process seems unnecessarily slow.

    | Thu 1 Jun 2017 22:37:39 #10 |

RSS feed for this topic

Reply »

You must log in to post.