Given that, what are the alternatives to gather requirements from large specification files with Scrum?
I'm afraid that there isn't any. It is either the Product Owner, the Scrum Team, or them together. Another option might be to hire an expert how can help out with the processing of the documentation.
Should the PM take care of it with a specification team?
By default yes, but in case of a large amount of complex work it is good when the Product Owner cooperates with the Scrum Team.
Or the development team should be more suitable for this kind of task?
I would say, yes. It seems that you have to do this kind of work on a regular basis. I assume these large specifications are vital to your business, which means that somebody has to do it. If the Product Owner is not enough than the team should help out. Maybe you can compensate the boring part with some "fedex day" like activities such as team members can pick what they'll do during a day.
The specification analysis should be time boxed into the sprint or it comes before Scrum can be applied?
If it is possible, this is the best solution. You can iteratively process the document and implement the features. If you have a backlog (user stories) for 2-3 Sprints ahead it is fine, and actually it is the best, because you don't create too much waste by defining user stories which may not be implemented.
In other words, it is not mandatory to process the whole requirement specification before starting the project. You create just enough user stories so that the team(s) can start to work and while they are working, the Product Owner continues the processing of the large requirement file, and puts the new user stories into the backlog.